Jelszavak, többfaktoros hitelesítés és munkamenet-védelem
Célok
A lecke végére meg tudod mondani, hogyan kell jelszót tárolni és miért nem jó a gyors hash, mit jelent a többfaktoros hitelesítés (MFA) és mit nem old meg, és mit kell tenni a munkamenet-azonosító védelméért.
Miért nem ér véget a jelszó ellenőrzésével a belépés biztonsága?
A bejelentkezés biztonsága több láncszemből áll: a jelszó tárolása, a második faktor, a munkamenet-azonosító kezelése és a kijelentkezés. Az egyik gyenge láncszem elég a fiókátvételhez. A támadó a jelszót ellophatja egy adatbázis-szivárgásból, kitalálhatja, adathalászattal kicsalhatja, vagy a belépés utáni munkamenet-azonosítót szerezheti meg. Mindegyikre külön védelem kell.
Jelszó ellenőrzése és tárolása
Belépéskor a szerver összeveti a megadott jelszót a korábban tárolt ellenőrző értékkel. A jelszót nem szabad olvasható formában tárolni, mert egy adatbázis-szivárgás azonnal felfedné. A tároláshoz jelszó-hash kell: egy egyirányú átalakítás, amelyből a jelszó nem állítható vissza.
De nem mindegy, milyen hash. A gyors, általános célú hash (például SHA-256, Secure Hash Algorithm) azért jó fájlokhoz, mert gyors; jelszóhoz éppen ez a baj, mert a támadó rengeteg tippet tud gyorsan kipróbálni. Kipróbáltuk ugyanazon a gépen, egy magon:
SHA-256: 20000 próba 16 ms alatt (~1 288 269 próba/s)
scrypt (N=2^17, r=8, p=1): 20 próba 3457 ms alatt (~6 próba/s)
A gyors hash több mint kétszázezerszer gyorsabb. Egy támadó, aki a hash-eket megszerezte, a sima SHA-256-tal másodpercenként több millió jelszót próbálhat ki, a költséges eljárással alig néhányat. Ezért jelszóhoz kifejezetten erre tervezett, lassú és erőforrásigényes eljárás kell.
Az OWASP jelszótárolási útmutatója a következő sorrendet ajánlja:
Argon2id (elsődleges): legalább 19 MiB memória, 2 iteráció, 1 párhuzamosság;
scrypt, ha az Argon2id nem elérhető (legalább N=2^17, r=8, p=1);
bcrypt régi rendszerekhez (legalább 10-es munkatényezővel, és 72 bájtos jelszóhossz-korláttal, mert a hosszabbat levágja);
PBKDF2, ha megfelelőségi okból kötelező (PBKDF2-HMAC-SHA256 legalább 600 000 iterációval).
(PBKDF2: Password-Based Key Derivation Function 2.) A fenti mérés scrypt-tel készült, mert a Node.js 24.4.1 beépített crypto moduljában a kipróbálásunk szerint nincs argon2Sync függvény; éles rendszerben bevált könyvtárat kell használni, saját megvalósítást soha.
Salt
Minden jelszóhoz egyedi, véletlen salt (só) tartozik. Ez megakadályozza az előre kiszámított táblázatok használatát, és azt, hogy a támadó egy menetben sok hash-t törjön fel. Kipróbálva ugyanazzal a jelszóval két különböző salttal:
azonos jelszó, két különböző salt:
0c4b569047729615f0fccb2af461261c...
44b17cf13358073209130e40f14c5c1d...
Az azonos jelszavakhoz tartozó tárolt értékek eltérnek, ezért a szivárgásból nem látszik, kik használták ugyanazt a jelszót. A legtöbb könyvtár a salt-ot automatikusan kezeli.
flowchart LR
P[Felhasználói jelszó] --> H[Lassú jelszó-hash + egyedi salt]
H --> D[(Tárolt ellenőrző érték)]
X[Belépéskor megadott jelszó] --> V[Ugyanazon eljárás szerinti ellenőrzés]
D --> V
V --> R{Egyezik?}
Jelszóhasználat és helyreállítás
A NIST (National Institute of Standards and Technology) hitelesítési irányelve (SP 800-63B) szerint a jelszavaknál a hosszúság számít: önálló jelszónál legalább 15 karakter, legalább 64 karakter megengedett hosszal; kötelező karakterkeverési szabályokat nem szabad előírni; nem szabad rendszeres jelszócserét kényszeríteni (csak kompromittálódás esetén); az új jelszót ellenőrizni kell az ismert, gyakori vagy kiszivárgott jelszavak listáján; és engedélyezni kell a jelszókezelőt és a beillesztést. A szerver oldalán fontos a próbálkozások számának korlátozása és az incidensek észlelése.
A jelszó-visszaállítás gyakran ugyanúgy fiókátvételi út lehet, mint a belépés, ezért a helyreállítási folyamat nem lehet gyengébb a belépésnél.
Többfaktoros hitelesítés
Az MFA (Multi-Factor Authentication, többfaktoros hitelesítés) legalább két különböző tényezőcsaládot kombinál: valamit, amit tudunk (jelszó), amit birtoklunk (hitelesítő eszköz, biztonsági kulcs), vagy ami a személyhez kötődik (biometria). Két egymás után kért jelszó nem két faktor. Az MFA csökkenti egy ellopott jelszó értékét, de nem teszi lehetetlenné a fiókátvételt: adathalászat, munkamenetlopás vagy rosszul védett helyreállítás továbbra is kockázat.
A módszerek erőssége eltér. A NIST irányelve szerint a jelszavak, az egyszer használatos kódok (OTP: one-time password) és az SMS-ben vagy más csatornán küldött kódok nem adathalászat-állóak, mert a felhasználót rá lehet venni a továbbadásukra. Adathalászat-álló az a kriptográfiai hitelesítés, amely az adott webhelyhez (a böngészőben az eredethez) kötött, ilyen például a WebAuthn/FIDO2 alapú biztonsági kulcs. A kurzus szempontjából a lényeg: a faktor valóban önálló bizonyíték legyen, és a helyreállítási út ne kerülhesse meg könnyebben a belépési védelmet.
Munkamenet mint belépés utáni kulcs
Sikeres hitelesítés után a munkamenet-azonosító vagy hozzáférési token bizonyítja a későbbi kérésekben, hogy a kliens egy már bejelentkezett folyamatot folytat (7.2, 7.3). Aki megszerzi ezt az értéket, a jelszó ismerete nélkül is használhatja a munkamenetet. Ezért:
az azonosító legyen nehezen kitalálható (véletlen, elég hosszú);
belépéskor és jogosultsági állapotváltáskor érdemes új azonosítót kiadni (a session fixation ellen);
legyen lejárat és szerveroldali érvénytelenítés;
a cookie legyen Secure (védett kapcsolathoz köti), HttpOnly (a JavaScript közvetlenül nem olvashatja) és SameSite (a kereszt-webhelyes küldést szabályozza). Ezek külön kockázat ellen hatnak: a HttpOnly nem állítja meg a sérült oldalon futó szkript minden műveletét (8.3), a SameSite pedig nem teljes CSRF-védelem (8.4).
Hitelesítési tokent a böngésző JavaScriptből elérhető localStorage vagy sessionStorage tárhelyén tartani kockázatos, mert XSS esetén a szkript hozzáférhet; a tárolásról a fenyegetési modell (8.1) alapján kell dönteni.
Kijelentkezés és időbeli korlátok
A NIST a hitelesítési szintektől függően különböző újrahitelesítési időkorlátokat ír elő (a magasabb szinteken rövidebbeket), ami jól mutatja, hogy az időbeli korlátok a kockázattal arányosak.
Végigvezetett példa: a Kurzuspont belépése
Elem
Döntés
Jelszótárolás
Argon2id vagy scrypt, egyedi salt, bevált könyvtárral.
Jelszókövetelmény
Legalább 15 karakter, hosszú jelszó, kiszivárgott jelszavak tiltása, nincs kötelező karakterkeverés vagy kényszerített csere.
Próbálkozások
Korlátozás és riasztás a sok sikertelen belépésre (10. fejezet: megfigyelhetőség).
MFA
Kötelező az oktatóknak, ajánlott a hallgatóknak; adathalászat-álló módszer előnyben.
Helyreállítás
Egyszer használatos, rövid életű hivatkozás; nem gyengébb a belépésnél.
Munkamenet
Véletlen azonosító, belépéskor új, HttpOnly; Secure; SameSite, rövid lejárat, szerveroldali kijelentkezés.
Gyakori tévhitek
Állítás
Pontosítás
„A jelszó SHA-256-tal hash-elve biztonságosan tárolható.”
Jelszóhoz költséges, erre tervezett eljárás és egyedi salt kell.
„Az MFA után a munkamenet már nem fontos.”
A megszerzett munkamenet-azonosító továbbra is használható lehet.
„A HttpOnly minden böngészős támadást kivéd.”
Csak a cookie közvetlen szkript-hozzáférését korlátozza.
„A kijelentkezés csak kliensoldali állapot.”
A szervernek az elfogadott hozzáférést is érvényteleníteni kell.
„Az SMS-kód adathalászat-álló.”
A NIST szerint az ilyen kódok továbbadhatók, ezért nem azok.
„Jobb a bonyolult jelszó, mint a hosszú.”
A hosszúság számít; kötelező karakterkeverést a NIST nem ír elő.
Röviden
A jelszót lassú, erre tervezett hash-sel és egyedi salttal tároljuk (Argon2id, scrypt); a gyors hash (SHA-256) nem jó.
A kipróbált gyors hash ~1,3 millió próba/s, a scrypt ~6 próba/s volt ugyanazon a gépen.
Az MFA különböző tényezőcsaládokat kombinál; a legerősebbek az adathalászat-álló módszerek.
A munkamenet-azonosító belépés utáni kulcs: véletlen, új belépéskor, lejáró, szerveroldalon érvényteleníthető.
Ellenőrző kérdések
Miért nem jó a sima SHA-256 jelszótárolásra?
Mit véd a salt?
Mi a különbség az MFA és két egymás utáni jelszó között?
Miért kell a kijelentkezésnek a szerveren is érvényteleníteni a munkamenetet?
Jelszavak, többfaktoros hitelesítés és munkamenet-védelem
Célok
A lecke végére meg tudod mondani, hogyan kell jelszót tárolni és miért nem jó a gyors hash, mit jelent a többfaktoros hitelesítés (MFA) és mit nem old meg, és mit kell tenni a munkamenet-azonosító védelméért.
Miért nem ér véget a jelszó ellenőrzésével a belépés biztonsága?
A bejelentkezés biztonsága több láncszemből áll: a jelszó tárolása, a második faktor, a munkamenet-azonosító kezelése és a kijelentkezés. Az egyik gyenge láncszem elég a fiókátvételhez. A támadó a jelszót ellophatja egy adatbázis-szivárgásból, kitalálhatja, adathalászattal kicsalhatja, vagy a belépés utáni munkamenet-azonosítót szerezheti meg. Mindegyikre külön védelem kell.
Jelszó ellenőrzése és tárolása
Belépéskor a szerver összeveti a megadott jelszót a korábban tárolt ellenőrző értékkel. A jelszót nem szabad olvasható formában tárolni, mert egy adatbázis-szivárgás azonnal felfedné. A tároláshoz jelszó-hash kell: egy egyirányú átalakítás, amelyből a jelszó nem állítható vissza.
De nem mindegy, milyen hash. A gyors, általános célú hash (például SHA-256, Secure Hash Algorithm) azért jó fájlokhoz, mert gyors; jelszóhoz éppen ez a baj, mert a támadó rengeteg tippet tud gyorsan kipróbálni. Kipróbáltuk ugyanazon a gépen, egy magon:
A gyors hash több mint kétszázezerszer gyorsabb. Egy támadó, aki a hash-eket megszerezte, a sima SHA-256-tal másodpercenként több millió jelszót próbálhat ki, a költséges eljárással alig néhányat. Ezért jelszóhoz kifejezetten erre tervezett, lassú és erőforrásigényes eljárás kell.
Az OWASP jelszótárolási útmutatója a következő sorrendet ajánlja:
(PBKDF2: Password-Based Key Derivation Function 2.) A fenti mérés scrypt-tel készült, mert a Node.js 24.4.1 beépített
cryptomoduljában a kipróbálásunk szerint nincsargon2Syncfüggvény; éles rendszerben bevált könyvtárat kell használni, saját megvalósítást soha.Salt
Minden jelszóhoz egyedi, véletlen salt (só) tartozik. Ez megakadályozza az előre kiszámított táblázatok használatát, és azt, hogy a támadó egy menetben sok hash-t törjön fel. Kipróbálva ugyanazzal a jelszóval két különböző salttal:
Az azonos jelszavakhoz tartozó tárolt értékek eltérnek, ezért a szivárgásból nem látszik, kik használták ugyanazt a jelszót. A legtöbb könyvtár a salt-ot automatikusan kezeli.
flowchart LR P[Felhasználói jelszó] --> H[Lassú jelszó-hash + egyedi salt] H --> D[(Tárolt ellenőrző érték)] X[Belépéskor megadott jelszó] --> V[Ugyanazon eljárás szerinti ellenőrzés] D --> V V --> R{Egyezik?}Jelszóhasználat és helyreállítás
A NIST (National Institute of Standards and Technology) hitelesítési irányelve (SP 800-63B) szerint a jelszavaknál a hosszúság számít: önálló jelszónál legalább 15 karakter, legalább 64 karakter megengedett hosszal; kötelező karakterkeverési szabályokat nem szabad előírni; nem szabad rendszeres jelszócserét kényszeríteni (csak kompromittálódás esetén); az új jelszót ellenőrizni kell az ismert, gyakori vagy kiszivárgott jelszavak listáján; és engedélyezni kell a jelszókezelőt és a beillesztést. A szerver oldalán fontos a próbálkozások számának korlátozása és az incidensek észlelése.
A jelszó-visszaállítás gyakran ugyanúgy fiókátvételi út lehet, mint a belépés, ezért a helyreállítási folyamat nem lehet gyengébb a belépésnél.
Többfaktoros hitelesítés
Az MFA (Multi-Factor Authentication, többfaktoros hitelesítés) legalább két különböző tényezőcsaládot kombinál: valamit, amit tudunk (jelszó), amit birtoklunk (hitelesítő eszköz, biztonsági kulcs), vagy ami a személyhez kötődik (biometria). Két egymás után kért jelszó nem két faktor. Az MFA csökkenti egy ellopott jelszó értékét, de nem teszi lehetetlenné a fiókátvételt: adathalászat, munkamenetlopás vagy rosszul védett helyreállítás továbbra is kockázat.
A módszerek erőssége eltér. A NIST irányelve szerint a jelszavak, az egyszer használatos kódok (OTP: one-time password) és az SMS-ben vagy más csatornán küldött kódok nem adathalászat-állóak, mert a felhasználót rá lehet venni a továbbadásukra. Adathalászat-álló az a kriptográfiai hitelesítés, amely az adott webhelyhez (a böngészőben az eredethez) kötött, ilyen például a WebAuthn/FIDO2 alapú biztonsági kulcs. A kurzus szempontjából a lényeg: a faktor valóban önálló bizonyíték legyen, és a helyreállítási út ne kerülhesse meg könnyebben a belépési védelmet.
Munkamenet mint belépés utáni kulcs
Sikeres hitelesítés után a munkamenet-azonosító vagy hozzáférési token bizonyítja a későbbi kérésekben, hogy a kliens egy már bejelentkezett folyamatot folytat (7.2, 7.3). Aki megszerzi ezt az értéket, a jelszó ismerete nélkül is használhatja a munkamenetet. Ezért:
Secure(védett kapcsolathoz köti),HttpOnly(a JavaScript közvetlenül nem olvashatja) ésSameSite(a kereszt-webhelyes küldést szabályozza). Ezek külön kockázat ellen hatnak: aHttpOnlynem állítja meg a sérült oldalon futó szkript minden műveletét (8.3), aSameSitepedig nem teljes CSRF-védelem (8.4).Hitelesítési tokent a böngésző JavaScriptből elérhető
localStoragevagysessionStoragetárhelyén tartani kockázatos, mert XSS esetén a szkript hozzáférhet; a tárolásról a fenyegetési modell (8.1) alapján kell dönteni.Kijelentkezés és időbeli korlátok
A NIST a hitelesítési szintektől függően különböző újrahitelesítési időkorlátokat ír elő (a magasabb szinteken rövidebbeket), ami jól mutatja, hogy az időbeli korlátok a kockázattal arányosak.
Végigvezetett példa: a Kurzuspont belépése
HttpOnly; Secure; SameSite, rövid lejárat, szerveroldali kijelentkezés.Gyakori tévhitek
HttpOnlyminden böngészős támadást kivéd.”Röviden
Ellenőrző kérdések
Tanulási források