Hogyan kell biztonságosan tárolni a jelszavakat?
A jelszót nem titkosítani és nem sima SHA-256-tal hash-elni kell. Ismerd meg a salt, pepper, work factor, Argon2id, scrypt és bcrypt szerepét.
Röviden
A jelszavakat egyirányú, lassú és lehetőleg memóriaigényes jelszóhash függvénnyel kell tárolni egyedi salttal. Modern általános ajánlásként az Argon2id erős választás; megfelelő konfigurációval scrypt vagy bcrypt is használható.
Miért nem visszafejthető formában tároljuk?
A szervernek bejelentkezéskor nem kell ismernie az eredeti jelszót. Elég ugyanazzal az eljárással feldolgozni a beírt jelszót, majd biztonságos összehasonlítással ellenőrizni az eredményt. Ha az adatbázis kiszivárog, így nincs közvetlenül visszafejthető jelszólista.
A plain text tárolás kritikus hiba. A visszafejthető titkosítás pedig felesleges központi titkot hoz létre: ha a visszafejtő kulcs megsérül, az összes jelszó egyszerre veszélybe kerülhet.
Mi az a salt és miért kell minden jelszóhoz?
A salt egy véletlenszerű, felhasználónként eltérő érték, amely a jelszóhash számításába kerül. Nem titok, ezért a hash mellett is tárolható. A szerepe az, hogy ugyanaz a jelszó két felhasználónál se ugyanazt a hashértéket adja, és ne lehessen előre számított rainbow table-t hatékonyan újrahasznosítani.
Ugyanaz a jelszó + eltérő salt = eltérő lenyomat
Jelszó
PeldaJelszo!
Egyedi salt
a91f
Demó lenyomat
Ez a vizualizáció SHA-256-tal szemlélteti a salt hatását; valódi jelszótároláshoz dedikált jelszóhash (pl. Argon2id) kell.
Argon2id, scrypt vagy bcrypt?
A jelszóhash célja éppen az, hogy drága legyen nagyon sok próbálkozást végrehajtani. Az Argon2id memóriaigényes és paraméterezhető, ezért a modern ajánlásokban gyakori első választás. A scrypt szintén memóriaigényes. A bcrypt régebbi, széles körben támogatott megoldás, de korlátozott bemeneti hossza és régebbi felépítése miatt új rendszernél sokszor nem ez az első választás.
A konkrét költségparamétert a saját infrastruktúrán kell mérni: legyen elég drága a támadónak, miközben a normál bejelentkezés elfogadható marad.
A pepper és az MFA más védelmi réteg
A pepper opcionális, szerveroldali titok, amelyet nem ugyanabban az adatbázisban tárolunk, mint a jelszóhash-eket. Nem helyettesíti a saltot. A többtényezős hitelesítés pedig akkor is csökkentheti a fiókátvétel kockázatát, ha a jelszó kiszivárog vagy adathalászattal megszerzik.
A jó jelszótárolás nem „algoritmusválasztás” egyetlen sorban: algoritmus + paraméterezés + egyedi salt + biztonságos összehasonlítás + frissítési stratégia együtt számít.
Gyakori kérdések
Elég SHA-256-tal hash-elni a jelszót?
Nem ajánlott. A SHA-256 túl gyors, ezért támadó hardveren nagyon sok jelszójelölt próbálható másodpercenként. Jelszóhoz dedikált, lassú jelszóhash függvény kell.
A salt titkos adat?
Nem. A saltnak egyedinek és lehetőleg véletlenszerűnek kell lennie, de tárolható a hash mellett. A pepper az, amely opcionális titkos komponens lehet.
Források és szabványok
Biztonsági témánál az elsődleges szabvány és a karbantartott szakmai útmutató fontosabb, mint egy véletlen implementációs példa. Az alábbi forrásokból érdemes továbbmenni.
Kapcsolódó ByBence