ugrás a tartalomhoz

Understanding Hash Functions and Keeping Passwords Safe

Joó Ádám · 2011. Jan. 18. (K), 20.20
Jelszavak kódolása az alapoktól
 ■
1

Miért segít a biztonságon az,

bugadani · 2011. Jan. 18. (K), 22.54
Miért segít a biztonságon az, hogy a jelszóval együtt tárolja az őt kódoló algoritmusra egyértelműen utaló karaktereket?
Mondjuk tanulságos volt a cikk abból a szempontból, hogy nekem nem jutott eszembe a hashfüggvény sebességének kihatása a biztonság kérdésére.
2

Több idő

Endyl · 2011. Jan. 19. (Sze), 14.01
Ha minden egyes jelszót más karakterlánccal sózol, akkor minden egyes jelszó feltöréséhez másik szivárványtáblát kellene építenie a tolvajnak (ez pedig nem kis idő).

Míg ha csak egy fajta karakterlácot használsz sózáshoz, és ahhoz is hozzájut, akkor elég csak egy szivárványtáblát generálnia, és megtalálja benne az egyszerű jelszavak többségét.
3

Azt hiszem nem fejeztem ki

bugadani · 2011. Jan. 19. (Sze), 14.28
Azt hiszem nem fejeztem ki magam eléggé jól az első körben. A sózás részével semmi problémám nincs. Engem az zavar a cikkben, hogy direkt hozzáfűzi a hash-hez a BLOWFISH-hez tartozó $2a karaktereket, ami engem kicsit zavar, ugyanis ha valaki megszerzi a hash-t, így tudja, hogy milyen algoritmus állította őt elő.
Idézem:
The resulting hash contains the algorithm ($2a), the cost parameter ($10), and the 22 character salt that was used. The rest of it is the calculated hash.
4

Ebben van valami

Endyl · 2011. Jan. 19. (Sze), 15.25
Valóban. Mondjuk annyival már nem nehéz kiegészíteni, hogy levegye az első 7 karaktert tárolás előtt, és akkor kevésbé árulkodó az adatbázis egyedül.

[szerk]
Ugyanakkor ha kellően lassúra állítjuk be az algoritmusunkat, és minden jelszót külön sózunk, a használt algoritmus ismeretében sem lesz kifizetődő a jelszavak feltörésére fordított idő, erőforrás.
[/szerk]
6

Kell

janoszen · 2011. Jan. 19. (Sze), 21.42
Egyrészt így működik az autentikáció szinte minden rendszerben és legjobb tudomásom szerint nem ez volt a biztonsági probléma sosem.

A másik oldalról ha ezt lehagyod, elveszted azt a lehetőséget, hogy esetleges hash algoritmus kompromittálódás esetén fájdalom mentesen átállj másra. Ez biztonsági szempontból szerintem sokkal nagyobb érv, mint az, hogy meg lehet tudni, hogy ahhoz az egy jelszóhoz milyen algoritmust használtál.
8

Ez nekem még mindig ködös egy

bugadani · 2011. Jan. 19. (Sze), 22.11
Ez nekem még mindig ködös egy kicsit. Attól még, hogy lecsapom a sztringből ezt a kulcsot, nyugodtan hozzáfűzhetem, esetleg ha nem tudom valami miatt pontosan, végigpróbálom az összes támogatott algoritmust és össze tudom vetni vele az eredményt. Nem értem, miért nehezítené 3, alapvetően fix karakter az átállást más algoritmusra.

De ezt tudjuk be a szűklátókörűségemnek.

Viszont a cikk alatt egy kommentelő megmondta a frankót. Aki megszerzi az adatbázist, illetve hozzáfér a szerverhez, beszúr egy naplózó kódot, ami eljuttatja hozzá a használt jelszavakat szövegesen, nem fog visszakereséssel bajlódni, csak ha direkt jelszavakra és nem egyéb személyes adatokra hajt.
5

A collisiont keveri a szerző

tgr · 2011. Jan. 19. (Sze), 18.42
A collisiont keveri a szerző a preimage-dzsel - collosion az, amikor tudsz generálni két olyan sztringet, aminek ugyanaz a hash-e. Jelszótöréshez ez eléggé hasznavehetetlen, preimage támadás meg nem ismert az md5 ellen.
7

Nem keveri

Joó Ádám · 2011. Jan. 19. (Sze), 22.06
Ha feltételezzük, hogy az algoritmus ugyanaz, egy másik fiókba is be tud jelentkezni a támadó az ütköző jelszóval.
9

Még egyszer, lassan:

tgr · 2011. Jan. 21. (P), 15.14
Még egyszer, lassan: collision attack az, amikor tudsz generálni két olyan stringet, aminek ugyanaz a hash-e.
10

Lassan

Joó Ádám · 2011. Jan. 23. (V), 06.24
Akkor most az előzőnél lassabban olvasd el, amit írtam.
11

Miért van az, hogy minél

tgr · 2011. Jan. 23. (V), 11.01
Miért van az, hogy minél kevésbé ért valaki valamihez, annál magabiztosabb? A collision attack azt jelenti, hogy meg tudsz adni egy olyan algoritmust, aminek nincs bemenete, és a kimenete két string, amiknek ugyanaz a hash-e. Ezt fel lehet használni pl. digitális aláírás elleni támadásokra, de jelszótörésnél legfeljebb arra jó, hogy létrehozz egy olyan acoountot, amibe két különböző jelszóval lehet bejelentkezni (ettől a kilátástól a legtöbb website-üzemeltető nem fakad sírva). A tényleges jelszótöréshez olyan algoritmusra lenne szükség, ami bemenetként megkap egy jelszó hash-et, és kimenetként kiad egy stringet, aminek ugyanaz a hash-e. Ezt first preimage attack-nak hívják, és az MD5 ellen nem ismert ilyen támadás. Az egyetlen probléma vele, hogy túl gyors.
13

Sóhaj

Joó Ádám · 2011. Jan. 25. (K), 01.11
Azt hiszem öregszem, úgyhogy most eltekintek a további vitrioltól. Csak, hogy átlásd:

A hash “collision” occurs when two different data inputs generate the same resulting hash. The likelihood of this happening depends on which function you use.


Írja a cikk szerzője, bevezetve a collision fogalmát, majd bemutat egy preimage támadást a crc32() ellen. Ezt követően megállapítja, hogy egy kellően nagy értékkészletű függvényre van szükség, mint amilyen az MD5.

Remélem feltűnt, hogy még csak szó sem esett collision attackról.

Mindezek után előrukkolsz azzal, hogy a szerző összekeveri a collisiont a preimage-dzsel, én jelzem, hogy nem, bár még nem teljesen értem, hogy mi a problémád.

Erre te lekezelő hangon, – és ha már lovagolunk a fogalmakon, javítva az előzőleg amúgy pontatlan meghatározást – további magyarázat nélkül leírod ugyanazt, a mellesleg még mindig nem teljesen egyértelmű dolgot.

Jelzem, hogy még mindig nem nyert, erre írsz egy hozzászólást adekvát terminológiával és meghatározásokkal, amikből végre kiderül, hogy mi volt a problémád. Persze már beláttuk, hogy a szerző nem keverte a két fogalmat, lévén az egyiket nem is használta, te keverted ide.

A lekezelő megjegyzés nélkül mondjuk lehetett volna rögtön ez az első hozzászólás, és sokkal kevesebb karakter után kell fizetni a számlát.
14

A szerző ezt írja: For

tgr · 2011. Jan. 25. (K), 21.39
A szerző ezt írja:

For example, md5() might be suitable, as it generates 128-bit hashes. This translates into 340,282,366,920,938,463,463,374,607,431,768,211,456 possible outcomes. It is impossible to run through so many iterations to find collisions. However some people have still found ways to do this (see here).


... és a (see here) az md5 elleni collision támadásra linkel, ami a szerző állításával szemben teljesen alkalmatlan egy adott jelszóval ütköző sztring előállítására.
15

Mit is ír

Joó Ádám · 2011. Jan. 26. (Sze), 04.01
Nem állítja, hogy a collision támadás alkalmas egy adott jelszóval ütköző sztring előállítására.

It is impossible to run through so many iterations to find collisions. However some people have still found ways to do this (see here).


Azt állítja, hogy ennyi iteráción nem lehetséges végigmenni, hogy ütközéseket találjunk. Habár, van akinek mégiscsak sikerült.

Szerencsétlen fogalmazás, de nem állítja.
12

Amire a cikk nem tér ki: az,

tgr · 2011. Jan. 23. (V), 15.25
Amire a cikk nem tér ki: az, hogy mi számít kellően lassú algoritmusnak, a processzorok fejlődésével folyamatosan változik, tehát arra is gondolni kell, hogyan tudsz később áttérni lassabb jelszóra. Ha pl. a lassítás abból áll, hogy sima md5 helyett a jelszó+só 10000 md5 iterációját végzed el, és valamikor a jövőben át akarsz térni 100000 iterációra, akkor egyszerűen csak át kell futtatnod a meglévő hasheket 90000 iteráción. A bcryptnél ilyen lehetőség nincs, ha megváltoztatod a lassító faktort, szükséged lesz az eredeti jelszóra az új hash kiszámításához, a régi hash nem elég. Ez nem katasztrófa, mert lehet az áttérést a user bejelentkezésére időzíteni, amikor tudjuk a jelszót, de a rendszer bonyolultabb lesz tőle, többféle jelszó sémát kell tudnia kezelni egyidőben.