A jelszó tárolásának alapelve közismert: ne mentsük el olvasható formában. Ebből azonban nem következik, hogy egy egyszerű SHA-256 hash már biztonságos megoldás. Az általános hash függvényeket nagy sebességre tervezték, a felhasználók pedig gyakran rövid, ismert mintákból álló jelszót választanak. Ha egy adatbázis kiszivárog, a támadó offline, korlátlan próbálkozással tesztelheti a jelölteket. A védelem célja ezért az, hogy minden egyes találgatás szándékosan drága legyen.

A jelszóhash nem titkosítás

A szervernek bejelentkezéskor nem kell visszanyernie az eredeti jelszót. Elég ugyanazzal a verifikációs algoritmussal ellenőrizni a megadott értéket. A visszafejthető titkosítás fölösleges kulcskockázatot hozna: a kulcs megszerzésével egyszerre minden jelszó olvashatóvá válna.

A hash-elés sem teszi sérthetetlenné a jelszót. A támadó jelölteket próbál, és összeveti az eredményt. A speciális password hashing ezt a keresést lassítja és memóriaigényessé teszi, hogy nagy GPU- vagy ASIC-farmmal is lényegesen drágább legyen.

A só minden rekordhoz egyedi munkát kényszerít

A salt véletlen, nyilvánosan tárolható érték, amely minden jelszóhash bemenetéhez hozzáadódik. Két azonos jelszó külön sóval külön eredményt ad. Így a támadó nem használhat egyetlen előre számított rainbow table-t az egész adatbázishoz, és nem látja azonnal, mely felhasználók választották ugyanazt a jelszót.

A sónak nem kell titkosnak lennie, de elég hosszúnak, véletlennek és rekordonként egyedinek kell lennie. A modern password hashing könyvtár generálja és a hash formátumába ágyazza. Felhasználónév vagy konstans alkalmazásnév nem megfelelő helyettesítő, mert kiszámítható és újrafelhasználódik.

Az Argon2id memóriát és időt kér

Az Argon2id modern, memóriaigényes jelszóhash-függvény. Paraméterei meghatározzák a memória mennyiségét, az iterációkat és a párhuzamosságot. A sok memória különösen fontos, mert a támadók tömeges párhuzamos hardverének költségét növeli, nem csupán néhány CPU-ciklust ad hozzá.

A paramétereket a saját produkciós hardveren kell kalibrálni. A cél érzékelhetően drága, de elfogadható bejelentkezés, például a szolgáltatás latency budgetjéhez illeszkedő száz milliszekundumos nagyságrend. Túl alacsony érték gyorsan elavul, túl magas pedig DoS-kockázatot és kapacitásproblémát okozhat.

A bcrypt továbbra is használható, de vannak korlátai

A bcrypt hosszú ideje széles körben támogatott, adaptív cost paraméterrel rendelkezik és megfelelő implementációval lényegesen jobb, mint egy gyors SHA hash. Meglévő rendszerekben nem kell pánikszerűen lecserélni, ha a költség megfelelő és a könyvtár helyesen kezeli.

Ugyanakkor a bemeneti hossz korlátozása, a karakterkódolás és az alacsony memóriaigény miatt új rendszerhez gyakran Argon2id az előnyösebb. A bcrypt 72 bájtos határa különösen meglepő lehet hosszú passphrase vagy előzetes átalakítás esetén. A választott könyvtár pontos viselkedését tesztelni kell.

A PBKDF2 protokoll- és megfelelőségi okból maradhat

A PBKDF2 sok iterációval ismétel egy pszeudovéletlen függvényt, és régi platformokon vagy szabályozott környezetben széles támogatást élvez. Memóriakeménysége gyengébb, ezért az iterációszámot rendszeresen felül kell vizsgálni. Nem minden „sok körös SHA” saját implementáció egyenértékű vele.

Ha kompatibilitás megköveteli, szabványos könyvtár és aktuális ajánlás szerinti paraméter szükséges. A formátum tárolja az algoritmust, PRF-et, iterációt, saltot és digestet, hogy később egyértelműen ellenőrizhető és migrálható legyen.

A pepper külön védelmi réteg lehet

A pepper szerveroldali titok, amely nincs a jelszóadatbázisban. Ha csak az adatbázis szivárog ki, a támadó enélkül nem tudja közvetlenül ellenőrizni a találgatásokat. A pepper kulcskezelőben vagy HSM-ben tartható, és kulcsolt előfeldolgozással kapcsolható a jelszóhoz.

Ez nem helyettesíti a sót vagy a lassú hash-t. Kulcsrotációja nehéz, mert az eredeti jelszó nem áll rendelkezésre minden rekord újraszámításához. Verziózott pepper és bejelentkezéskori migráció szükséges, kompromittálódáskor pedig világos incidensfolyamat.

A hash formátuma hordozza a paramétereket

Jó könyvtár önleíró stringet tárol: algoritmusazonosítót, verziót, cost paramétereket, saltot és eredményt. Így ugyanabban a táblában különböző korszakok jelszóhash-ei élhetnek, a verifier pedig rekord alapján választ megfelelő ellenőrzést.

Külön oszlopok is használhatók, de a saját formátum hibalehetőséget ad. Nem szabad csak a digestet menteni és a paramétereket globális konfigurációra bízni, mert egy későbbi változtatás ellenőrizhetetlenné teheti a régi fiókokat.

A rehash bejelentkezéskor fokozatos migrációt ad

Amikor a felhasználó helyes jelszóval jelentkezik be, az alkalmazás rövid időre ismeri a plaintextet. Ha a tárolt algoritmus vagy cost elavult, ugyanabban a sikeres folyamatban új hash készíthető. Így tömeges jelszó-visszaállítás nélkül erősödik az aktív fiókok védelme.

A migráció legyen tranzakciósan és versenyhelyzetben biztonságos. Két párhuzamos login ne írjon vissza gyengébb vagy inkompatibilis értéket. A metrika mutassa a régi formátumok arányát, hogy a csapat eldönthesse, mikor kell az inaktív fiókokkal külön foglalkozni.

A hosszkorlát egyszerre biztonsági és használhatósági kérdés

A rövid maximum gyengíti a passphrase-eket, a korlátlan, több megabájtos bemenet viszont a drága hash miatt DoS-eszköz lehet. Ésszerű, dokumentált bájthatár szükséges, amely bőven támogat hosszú jelszavakat, de megvédi az erőforrást.

A karaktereket egységes kódolásban kell átadni a függvénynek. Csendes csonkolás tilos. Unicode-normalizálás vitatott, mert megváltoztathatja a felhasználó titkát; ha a termék alkalmazza, ugyanúgy kell működnie regisztrációkor, belépéskor és minden kliensen.

A rate limit továbbra is szükséges

A lassú hash az offline adatbázis-támadást drágítja, de az online login endpointot nem védi teljesen. IP-, fiók- és kockázatalapú rate limit, fokozatos késleltetés, botvédelem és többfaktoros hitelesítés csökkenti a credential stuffingot.

A limit ne tegye könnyűvé más felhasználó fiókjának zárolását. A hibaüzenet ne árulja el, létezik-e az e-mail, a monitoring pedig különítse el a rossz jelszót, a blokkolt próbálkozást és az infrastruktúrahibát. A hash latency növekedése kapacitásriasztás is lehet.

A jelszó nem kerülhet logba vagy analitikába

A legjobb hash sem segít, ha a plaintext request body debug logba, APM trace-be, exception contextbe vagy kliensoldali analytics eseménybe kerül. A credential mezőket minden megfigyelési rétegben explicit redakció védi, és a hibajelentés nem ismétli vissza az inputot.

Memóriában is csak a szükséges ideig maradjon. Magas biztonsági környezetben speciális secret típus és zeroization csökkentheti a kitettséget, bár managed runtime-ban nincs teljes garancia. A legfontosabb továbbra is a hozzáférések és adatfolyamok minimalizálása.

A jelszó-visszaállítás új credential létrehozása

Mivel a rendszer nem tudja visszafejteni a régi jelszót, „emlékeztetőt” sem küldhet. A reset rövid életű, egyszer használható tokennel hitelesíti a műveletet, majd új password hash készül. A token maga is biztonságos véletlen, scope-olt és visszavonható.

Sikeres visszaállítás után a régi sessionök és refresh tokenek kezeléséről policy dönt. Gyanús eseménynél érdemes szélesebb revokációt és értesítést alkalmazni. A reset endpoint ugyanazt a rate limitet és auditot igényli, mint a login.

A jó jelszóhash-rendszer idővel erősödik

Nincs örökre megfelelő cost érték. A hardver gyorsul, a felhasználói szám és a szerverkapacitás változik, új könyvtárverziók jelennek meg. Éves vagy rendszeres benchmark alapján emelhető a költség, az önleíró formátum és rehash pedig lehetővé teszi a fokozatos átállást.

A védelem lényege nem egy algoritmusnév kipipálása. Egyedi só, modern memóriaigényes függvény, gondosan választott paraméter, biztonságos könyvtár, online védelem és migrációs terv együtt teszi drágává a kiszivárgott adatbázis elleni támadást.