Warum ein langsamer Hash
Wenn eine Datenbank leakt, raten Angreifer Passwörter offline gegen die gespeicherten Hashes. Ein schneller Hash wie SHA-256 lässt eine einzelne GPU etwa zehn Milliarden Versuche pro Sekunde machen, was die meisten von Menschen gewählten Passwörter binnen Stunden in Klartext verwandelt. Passwort-Hash-Funktionen sind absichtlich langsam und in den neueren Entwürfen speicherhungrig, sodass jeder Versuch den Angreifer so viel kostet wie Sie, und die tausenden Kerne einer GPU nicht helfen, weil sie sich zu wenig Speicher teilen.
| Funktion | Jahr | Einstellbar | Empfohlen (OWASP 2024) | Einsatz |
|---|---|---|---|---|
| Argon2id | 2015 | Speicher, Durchläufe, Lanes | m=19 MiB, t=2, p=1 (oder m=64 MiB, t=3) | Vorgabe für neue Systeme. Sieger der Password Hashing Competition. |
| scrypt | 2009 | N, r, p | N=2¹⁷, r=8, p=1 | Speicherhart; gut, wo Argon2 fehlt. |
| bcrypt | 1999 | Cost (2ⁿ Runden) | Cost 10 oder mehr | Überall; weiterhin solide. Kürzt bei 72 Byte ab. |
| PBKDF2 | 2000 | Iterationen | 600.000 (SHA-256) | FIPS-Konformität; nicht speicherhart, also am schwächsten gegen GPUs. |
Einen Hash-String lesen
$2b$12$ + 22 Zeichen Salt + 31 Zeichen Hash: bcrypt, Cost 12 (4.096 Runden). $argon2id$v=19$m=19456,t=2,p=1$salt$hash: Argon2id mit seinen Parametern im String, Base64 ohne Padding. Beide Formate tragen alles Nötige zum Prüfen, sodass Sie die Kosten mit der Zeit erhöhen und Nutzer beim nächsten Login neu hashen können. scrypt und PBKDF2 haben kein universelles String-Format; Salt und Parameter werden daneben gespeichert, weshalb der Prüfer den Salt getrennt abfragt.
Kosten wählen
Zielen Sie auf etwa 100–300 ms pro Hash auf Ihrem Server. Diese Seite zeigt, wie lange jeder Hash in Ihrem Browser gedauert hat (ein ordentlicher Laptop ist mit einem kleinen Serverkern vergleichbar). Argon2 mit den empfohlenen 19 MiB braucht in JavaScript etwa eine Sekunde; native Implementierungen sind mehrfach schneller.
Was man nicht tun sollte
Verwenden Sie nicht MD5, SHA-1 oder SHA-256 allein, auch nicht gesalzen. Verwenden Sie keinen einzelnen Salt für die ganze Website. Hashen Sie nicht mit SHA-256 vor, um bcrypts 72-Byte-Grenze zu umgehen, es sei denn, Sie kodieren das Ergebnis Base64 (rohe Bytes können NUL enthalten, wo bcrypt abbricht). Und fügen Sie keine echten Produktionspasswörter in eine Webseite ein, auch nicht in diese; nehmen Sie Testwerte.
Fragen
Kann ich diese Seite mit einem echten Passwort nutzen?
Das Hashing läuft in Ihrem Browser und nichts wird übertragen, aber die vernünftige Regel ist, jede Webseite für echte Zugangsdaten als nicht vertrauenswürdig zu behandeln. Nutzen Sie sie für Hashes in Test-Fixtures, zum Verstehen der Formate und zum Prüfen mit Wegwerf-Passwörtern.
Warum liefert bcrypt jedes Mal einen anderen Hash?
Der Salt ist bei jedem Aufruf zufällig; er wird im Hash-String gespeichert. Die Prüfung extrahiert ihn und rechnet neu. Zwei Hashes desselben Passworts unterscheiden sich erwartungsgemäß; beide verifizieren.
Warum schlägt meine bcrypt-Prüfung bei einem langen Passwort fehl?
bcrypt verwendet nur die ersten 72 Byte. Wurde das Passwort von einer Bibliothek gehasht, die vorhasht (manche Django- und Passlib-Konfigurationen), passt die rohe bcrypt-Prüfung hier nicht. Prüfen Sie auch das Präfix: $2y$ und $2b$ sind kompatibel; $2x$ kennzeichnet eine fehlerhafte Implementierung.
Was bedeuten m, t und p bei Argon2?
m ist der Speicher in KiB (19456 = 19 MiB), t die Zahl der Durchläufe über diesen Speicher, p die Zahl der Lanes, die parallel laufen können. Speicher ist der wichtigste Sicherheitsregler: Er macht GPU- und ASIC-Angriffe teuer.