Egy jelszó hash-elésénél a sózás tulajdonképpen hogy működik? Visszaellenőrzéshez UGYANAZT a bájtláncot, ami a hash-elésnél salt-nak használva volt, újra kell tudni generálni? Vagy ez az adat tényleg csak obfuszkációhoz volt használva, és eldobható?

Akkor menjünk végig a gondolati láncon:

1. megoldás: jelszó tárolása szövegként. Probléma: Ha valaki megszerzi az adatbázist, tudni fogja mindenkinek a jelszavát.

2. megoldás: Valamilyen hash algoritmust használva a jelszó hash-ét tároljuk és a bejelentkezésnél a jelszót hash-ét hasonlítsuk össze az adatbázisban tárolttal. Probléma: szivárványtáblával – ismert szövegek és hash-ük párosának kisebb-nagyobb adatbázisával – az egyszerű jelszavak visszafejthetők.

3. megoldás: Tegyük hosszúvá akkor a rövid jelszavakat is. A jelszót egy statikus „sóval” megtoldva generáljuk a hash-t, hiszen az „password” jelszót könnyű visszafejteni, de a „password+ez_itt_a_statikus_só_pistike_weboldalához”-t biztos nem lehet szivárványtáblával visszafejteni. Probléma: azonos jelszavak esetén azonos hash-t fog generálni, így a gyakori jelszavak hash-e az adatbázisban szintén gyakori lesz. Lehet, hogy a „b5a986cba6bef5ae681f29d3da47cb50” jelszót nem tudom konkrétan visszafejteni, de mivel 83 felhasználónak is ez a jelszó hash-e az adatbázisban, ezért jó eséllyel egy gyakori jelszót takar, pl. „12345”, „password”, „qwerty” vagy „iloveyou”. Illetve a probléma az, hogy ha valamilyen módon sikerül kideríteni, hogy mi a só, akkor rögtön könnyebb visszafejteni a jelszavakat – legalábbis az egyszerűbbeket – a hash-ekből. (Ha ugyanaz a só, akkor már megéri szótár módszerrel legenerálni a fix sót alkalmazó saját szivárványtáblát.)

4. A megoldás tehát az,hogy minden felhasználó esetén egyedi sót használunk. Itt két út van:

4.1. Generáljunk sót a felhasználó ismert és nem változó adatából. Mondjuk a regisztrációnál használt email címének hash-éből. Az előny, hogy a sót nem kell tárolni, hiszen az bármikor újra generálható. A hátrány, hogy ha kiszivárog a só generálási módszer, akkor megint kicsit könnyebb lesz a tárolt hash-ekből a jelszavakat visszafejteni. Azért sem szerencsés így eljárni, mert só hosszát vagy a generálási módját erősen nehézkes onnantól megváltoztatni. Akkor is bajban vagyunk, illetve észnél kell lenni, ha később igény van arra, hogy a felhasználó változtatni tudjon az addig változtathatatlannak tartott adatán (pl. tudjon a felhasználói fiókja megmaradásával bejelentkezési email címet változtatni).

4.2. Az általánosan elterjedt megoldás, hogy teljesen random sót generálunk, ami mindentől független. Ehhez persze le kell tárolni azt is, de ez nem akkora probléma, hiszen nem lehet egy minden felhasználónál használható, de az adott rendszer adatbázisára kihegyezett szivárványtáblát generálni. A só hossza vagy generálási algoritmusa sokkal könnyebben változtatható.

~ ~ ~

+1 tipp: Az általános célú hash algoritmusokat – md5, sha, ha van rá mód, érdemes kerülni. Ezek megtervezésénél – lévén általános célúak – fontos szempont, hogy gyorsak legyenek, párhuzamosítható legyen a futtatásuk stb… Gyorsnak kell lenniük, ha mondjuk egy 1 GB-os fájl hash-ét ellenőrzőösszegként akarom legenerálni. Ha van rá mód, érdemes olyan hash algoritmust alkalmazni, amiket kimondottan lassúra sőt kimondottan jelszó hashelésre terveztek. Pl.: argon2, scrypt, bcrypt stb…

PHP esetén pl. nem kell feltalálni a meleg vizet, ott vannak a beépített password_hash, password_verify, password_needs_rehash függvények.