Mitől véd valójában egy jelszó hash-elése

A rövid változat

A jelszó hash-elése akkor védi a felhasználókat, amikor ellopják a jelszó-adatbázisodat.

Ez a fő feladata. Nem az egyetlen részlet, nem a teljes biztonsági modell, de ez a központi oka annak, hogy a jelszavakat hash-eljük, nem pedig közvetlenül tároljuk.

Egy megfelelően hash-elt jelszót nehéz visszafejteni. Ha egy támadó megszerzi a felhasználói táblád másolatát, nem szabadna azonnal megtudnia, hogy Alice jelszava Spring2026!. Ehelyett egy tárolt hasht kap, amelynek találgatásokkal szembeni tesztelése időbe, pénzbe és hardverbe kerül.

Ez a különbség számít. A jelszóhash-elés önmagában nem arra való, hogy biztonságossá tegye a bejelentkezést. Nem állítja meg az adathalászatot. Nem akadályozza meg, hogy valaki kiszivárgott jelszavakat próbálgasson a bejelentkezési űrlapodon. Nem védi meg a munkamenet-sütit bejelentkezés után. Időt nyer és csökkenti a kárt egy nagyon konkrét hiba után: amikor a jelszó-ellenőrző adatok tárolója nyilvánossá válik.

Ha érted ezt a határt, jobb döntéseket fogsz hozni algoritmusokról, költségparaméterekről, jelszó-visszaállításokról, naplózásról és incidenskezelésről.

Mi az a jelszóhash

A jelszóhash egy jelszóra alkalmazott egyirányú függvény kimenete, általában egyedi salttal és szándékosan lassú jelszóhash-elő algoritmussal.

Amikor egy felhasználó fiókot hoz létre, a rendszernek nagyjából ezt kell tennie:

1. Fogadja a jelszót HTTPS-en keresztül.
2. Generál egy véletlenszerű, egyedi saltot.
3. Lefuttatja a jelszót és a saltot egy jelszóhash-elő függvényen, például Argon2id, bcrypt, scrypt vagy PBKDF2 használatával.
4. Eltárolja az algoritmus nevét, a paramétereket, a saltot és a kapott hasht.
5. Eldobja az eredeti jelszót.

Amikor a felhasználó később bejelentkezik, a rendszer megismétli ugyanazt a hash-elési folyamatot a beküldött jelszóval és a tárolt paraméterekkel. Ha a kapott hash egyezik a tárolt hash-sel, a bejelentkezés sikeres.

A lényeg: az alkalmazásnak nem kell ismernie az eredeti jelszót. Csak azt kell ellenőriznie, hogy a beküldött jelszó a várt eredményt állítja-e elő.

Ezért általában rossz modell a jelszavak visszafejthető titkosítással való tárolása. Ha az alkalmazásod minden jelszót vissza tud fejteni, akkor bárki, aki ellopja a visszafejtési kulcsot, ugyanezt megteheti. A jelszavaknak normál esetben visszafelé nem ellenőrizhetőnek kell lenniük, nem pusztán elrejtettnek.

Mitől véd a hash-elés

1. Azonnali jelszófeltárás adatbázis-incidens után

Ha egy támadó ellop egy nyílt szövegű jelszavakat tartalmazó adatbázist, a kár azonnali. Minden jelszó kikerül. A felhasználók nemcsak a te oldaladon vannak veszélyben, hanem mindenhol, ahol ugyanazt a jelszót újrahasználták.

Ha az adatbázis jól hash-elt jelszavakat tartalmaz, a támadónak több dolga van. Jelszójelölteket kell találgatnia, minden tippet a megfelelő salttal és paraméterekkel kell hash-elnie, majd össze kell hasonlítania az eredményt.

Gyenge jelszavaknál ez még mindig gyors lehet. Erős, egyedi jelszavaknál gyakorlatilag kivitelezhetetlenné válhat.

A hash-elés egy katasztrofális feltárást versenyfutássá alakít: vissza tudják-e állítani a felhasználók a jelszavaikat, és meg tudod-e fékezni az incidenst, mielőtt a támadók sok jelszót feltörnek?

Ez nem tökéletes. Ez továbbra is incidens. De drámaian jobb hibamód.

2. Tömeges támadások a teljes felhasználói bázis ellen

A saltok kulcsfontosságúak a jelszótárolásban, mert megakadályozzák, hogy a támadók előre kiszámított táblákkal hatékonyan támadjanak egyszerre sok felhasználót.

A salt nem titok. A hash mellett tároljuk. A feladata az egyediség.

Ha két felhasználó ugyanazt a jelszót választja, az egyedi saltok biztosítják, hogy a tárolt hash-eik különbözzenek. Ez megakadályozza, hogy a támadók ránézésre lássák, hogy sok felhasználó ugyanazt a jelszót használja. Megakadályozza a klasszikus rainbow table támadásokat is, amikor a támadók hatalmas, előre kiszámított jelszó-hash megfeleltetési listákat használnak.

Saltok nélkül egyetlen feltört hash felfedheti az összes felhasználót, aki ugyanazt a jelszót használja. Saltokkal minden jelszótippet külön kell tesztelni minden felhasználóra.

3. Gyors offline találgatás

Miután a támadók megszerezték a jelszó-adatbázist, offline találgathatnak. Ez azt jelenti, hogy a bejelentkezési rate limit, a CAPTCHA, az IP-blokkolás és a monitorozás már nem számít. A támadó a saját hardverén tesztelheti a tippeket.

Itt számít az algoritmusválasztás.

Az általános célú hashek, például a SHA-256 és a SHA-512 gyors működésre készültek. Ez jó fájlintegritáshoz és digitális aláírásokhoz. Jelszótároláshoz rossz.

A jelszóhash-elő algoritmusok úgy készültek, hogy lassúak, hangolhatók és néha memóriaigényesek legyenek. Az Argon2id, a bcrypt, a scrypt és a PBKDF2 mind lehetővé teszi a költségparaméterek beállítását, hogy minden egyes tipp érdemi időbe kerüljön.

Az Argon2id széles körben ajánlott új rendszerekhez, mert beállítható úgy, hogy CPU-időt és memóriát is igényeljen, ami drágábbá teszi a nagy léptékű GPU-s feltörést. A bcrypt továbbra is gyakori és megfelelő, ha jól van konfigurálva, bár vannak korlátai, például a jelszóhossz kezelésében. A PBKDF2-t még mindig használják egyes megfelelőségvezérelt környezetekben, különösen ott, ahol FIPS-validált komponensekre van szükség.

Az alapelv egyszerű: a legitim bejelentkezések legyenek elfogadhatóan gyorsak, miközben a milliárdnyi találgatás legyen drága.

Mitől nem véd a hash-elés

1. Adathalászat

Ha egy felhasználó egy hamis bejelentkezési oldalra írja be a jelszavát, a szervereden végzett hash-elés nem segít. A támadó még azelőtt megkapja a jelszót, hogy a rendszered valaha látná.

Itt más védekezések kellenek: többtényezős hitelesítés, passkeys, felhasználói oktatás, domain-higiénia, adathalászatnak ellenálló hitelesítés és gondosan megtervezett jelszó-visszaállítási folyamatok.

A jelszóhash-elés védőháló a tárolt titkokhoz. Nem védelem az ellen, hogy a felhasználókat rászedjék a titkaik átadására.

2. Credential stuffing

Credential stuffing akkor történik, amikor a támadók egy szolgáltatásból kiszivárgott felhasználónév-jelszó párokat egy másik szolgáltatáson próbálnak ki.

A jelszóhash-eid lehetnek kiválóak, a credential stuffing mégis működhet, ha a felhasználók újrahasználják a jelszavaikat.

Ez online támadás a bejelentkezési űrlapod ellen, nem offline támadás az adatbázisod ellen. Rate limitingre, anomáliadetektálásra, kiszivárgott jelszavak ellenőrzésére, MFA-ra és ésszerű kizárási szabályokra van szükség, amelyek nem teremtenek könnyű denial-of-service lehetőségeket.

Ugyanez a gyakorlati gondolkodás vonatkozik bármely nyilvános űrlapra. Ha az autentikációs felületedet vizsgálod, érdemes elolvasni, miért a kapcsolatfelvételi űrlapod a legnagyobb spamkockázatod; a mechanika eltér, de a tanulság hasonló: a nyilvános bemenetekhez visszaélés elleni kontrollok kellenek, nem csak tiszta backend kód.

3. Naplókban vagy analitikában rögzített jelszavak

A hash-elés csak akkor segít, ha a nyílt szövegű jelszót gyorsan eldobjuk, és soha nem másoljuk máshová.

Gyakori hibák:

• Teljes request body-k naplózása sikertelen bejelentkezési kísérleteknél.
• Jelszavak küldése hibamonitorozó eszközökbe.
• Jelszómezők rögzítése session replay termékekben.
• Hitelesítő adatok URL-ekbe tétele rosszul megtervezett visszaállítási vagy migrációs folyamatokban.
• Ideiglenes nyílt szövegű jelszavak tárolása importálás közben.

Ezek a hibák teljesen megkerülik a jelszóhash-elést. Ha a nyílt szöveg naplókba, biztonsági mentésekbe, adattárházakba vagy külső eszközökbe kerül, a hash-függvényed irreleváns.

Kezeld a jelszómezőket mérgező adatként. Naplózás előtt takard ki őket. Zárd ki őket az analitikából. Tartsd távol őket az URL-ektől. Korlátozd, ki férhet hozzá az éles nyomkövetési adatokhoz.

4. Gyenge munkamenet-biztonság

Bejelentkezés után a felhasználó böngészője általában kap egy munkamenet-sütit vagy tokent. Ha ezt a tokent ellopják, a támadónak lehet, hogy egyáltalán nincs szüksége a jelszóra.

A jelszóhash-elés nem véd a cross-site scripting, a nem biztonságos sütik, a session fixation, a gyenge tokengenerálás vagy a túl hosszú munkamenet-élettartamok ellen.

A munkamenet-sütik külön felülvizsgálatot érdemelnek: HttpOnly, Secure, megfelelő SameSite, rövid életű magas kockázatú munkamenetek és szerveroldali érvénytelenítés jelszóváltoztatáskor. A tágabb adatvédelmi és böngészős környezet is folyamatosan változik, ahogy azt bemutatja mi változott a sütiknél 2026-ban.

5. Gyenge jelszó-visszaállítás és fiók-helyreállítás

Sok fiókátvétel nem a jelszóval kezdődik. A visszaállítási folyamattal kezdődik.

Ha a visszaállítási tokenek kiszámíthatók, hosszú életűek, referrer fejléceken keresztül kiszivárognak, vagy kompromittált email-fiókokba érkeznek, a jelszóhash-elés nem fog megmenteni.

Használj nagy entrópiájú visszaállítási tokeneket, rövid lejárati időt, egyszeri felhasználást és egyértelmű felhasználói értesítéseket. Mivel gyakran az email a helyreállítási csatorna, az alapvető domain-hitelesítés is számít. Ha a csapatod rejtélyes szertartásként kezeli a DNS-rekordokat, kezdd az MX, SPF, DKIM és DMARC fejlesztőbarát áttekintésével.

Algoritmusválasztás: mit használj most

Új alkalmazásokhoz használj Argon2id-t, ha a platformod jól támogatja. Ez a Password Hashing Competition győztese, és jelszótárolásra tervezték, beleértve a GPU-központú feltöréssel szembeni ellenállást is.

Egy ésszerű modern hierarchia így néz ki:

1. Argon2id új rendszerekhez, ahol elérhető.
2. bcrypt, ha az Argon2id nem praktikus, és a bcrypt támogatása érett.
3. scrypt, ha a memóriaigényes konfiguráció jól támogatott.
4. PBKDF2, ahol platform- vagy megfelelőségi korlátok megkövetelik.

Kerüld a sima SHA-256, SHA-512, MD5 használatát, illetve az olyan házi kombinációkat, mint a sha256(password + salt). A gyors hashek nem jelszótároló függvények. Az okos egyedi konstrukciók általában rosszabbak, mint az unalmas szabványosak.

Azt is kerüld, hogy algoritmikus apróságok köré találj ki saját jelszópolitikát. A felhasználóknak nem segít egy 12 szabályos jelszó-összetételi ellenőrzőlista, ha kiszámítható minták felé tolja őket. A hosszabb egyedi jelszavak, a jelszókezelők, a kiszivárgott jelszavak szűrése és az MFA általában többet számítanak.

A költségparaméterek nem „beállítod és elfelejted” típusúak

A jelszóhash-elésnek paraméterei vannak. Az Argon2id memóriát, iterációkat és párhuzamosságot használ. A bcryptnek költségfaktora van. A PBKDF2-nek iterációszáma.

Ezeket az értékeket az éles környezeted alapján kell megválasztani. Túl alacsonyan a támadók olcsón találgathatnak. Túl magasan a bejelentkezési rendszered lassúvá vagy denial-of-service támadásokkal szemben sérülékennyé válik.

Gyakorlati célként sokszor jelszó-ellenőrzésenként néhány tíz és néhány száz milliszekundum közötti tartomány adódik a tényleges szervereiden, a forgalomtól és a kockázattól függően. Magas biztonságú rendszerek választhatnak többet. Fogyasztói léptékű rendszereknél gondos kapacitástervezésre lehet szükség.

Ne másolj ki költségfaktort egy ötéves blogbejegyzésből. A hardver változik. A könyvtárak változnak. A forgalmad változik.

Időnként vizsgáld felül a paramétereket, és tervezz újrahash-eléssel. Gyakori minta, hogy minden hash mellett tároljuk az algoritmust és a paramétereket. Sikeres bejelentkezéskor, ha a tárolt paraméterek elavultak, a beküldött jelszót az újabb konfigurációval újrahash-eljük, és frissítjük a rekordot.

Pepperek: hasznosak, de nem helyettesítők

A pepper egy titkos érték, amelyet hozzáadunk a jelszóhash-elési folyamathoz, és az adatbázistól elkülönítve tárolunk, gyakran secrets managerben vagy hardware security module-ban.

A salttal ellentétben a peppernek titokban kell maradnia.

A pepperek csökkenthetik a kárt, ha az adatbázis kiszivárog, de az alkalmazástitkok nem. Leginkább érett, jó kulcskezeléssel rendelkező környezetekben hasznosak. Kevésbé hasznosak, ha ugyanaz a támadó az adatbázist és az alkalmazáskonfigurációt is el tudja lopni.

Ha peppert használsz, gondosan tervezd meg a rotációt. A rotáció a kialakítástól függően megkövetelheti, hogy a felhasználók újra bejelentkezzenek vagy jelszót állítsanak vissza. A pepper egy további réteg, nem ok arra, hogy gyengítsd az alapul szolgáló hash-beállításokat.

Az üzemeltetési ellenőrzőlista

Ha valódi rendszerért felelsz, a gyakorlati ellenőrzőlista rövid:

• Jelszavakat csak szabványos jelszóhash-elő algoritmussal tárolj.
• Használj jelszavanként egyedi, véletlenszerű saltot.
• Új fejlesztéseknél részesítsd előnyben az Argon2id-t.
• A költségparamétereket éleshez hasonló hardveren hangold.
• Minden hash mellett tárold az algoritmust és a paramétereket.
• Jelentkezéskor hash-elj újra, amikor a paraméterek elavulnak.
• Soha ne naplózz jelszavakat, és ne küldd őket analitikai eszközökbe.
• Használj TLS-t mindenhol, ahol hitelesítő adatokat küldenek be.
• Adj hozzá MFA-t vagy passkeys-t ott, ahol a kockázat indokolja.
• A visszaállítási folyamatokat kezeld ugyanolyan komolyan, mint a bejelentkezési folyamatokat.
• Legyen incidens-terved kényszerített visszaállításokra és felhasználói értesítésre.

A jelszóhash-elés nem látványos. Infrastruktúra. De olyan infrastruktúra, amely eldönti, hogy egy incidens fájdalmas eseménnyé vagy az összes felhasználót érintő katasztrófává válik-e.

<!-- tool-cta:start -->

💡 Próbálja ki: Nézze meg, hogyan képeződik le ugyanaz a bemenet különböző algoritmusokra a Hash Generator segítségével, amely kézzelfoghatóvá teszi a gyors hashek és a jelszószintű hashek közötti különbséget.

<!-- tool-cta:end -->

Az őszinte mentális modell

A jelszóhash-elésről így érdemes gondolkodni:

A hash-elés nem védi a jelszót, miközben a felhasználó begépeli. Nem védi a fiókot azután, hogy a felhasználó bejelentkezett. Nem védi azokat a felhasználókat, akik ugyanazt a jelszót több helyen használják a weben.

A tárolt ellenőrző adatot védi.

Ez szűknek hangzik, de rendkívül fontos. Adatbázisok szivárognak. Biztonsági mentések szivárognak. Staging rendszereket másolnak. Beszállítók olyan hozzáférést kapnak, amelyet nem kellene. Régi exportok maradnak objektumtárolókban tovább, mint bárki emlékszik rá.

Amikor ez megtörténik, a jelszótárolási kialakításod jelenti a különbséget aközött, hogy a támadók jelszavakat kapnak, vagy egy drága találgatási problémát.

Valójában ettől véd egy jelszó hash-elése.