Sollte ich bcrypt oder Argon2 verwenden?

Argon2id für neue Systeme: Es hat die Password Hashing Competition gewonnen und ist memory-hard, was GPU- und ASIC-Cracking deutlich teurer macht. bcrypt ist weiterhin akzeptabel und sehr breit unterstützt; behalten Sie es, wenn Ihr Stack es bereits nutzt.

Warum ist der Hash für dasselbe Passwort jedes Mal anders?

Jeder Hash verwendet ein neues zufälliges Salt, daher ändert sich die Ausgabe jedes Mal. Das ist so gewollt. Um ein Passwort zu prüfen, verifizieren Sie es gegen den gespeicherten Hash, statt zwei frisch erzeugte Hashes zu vergleichen.

Kann man einen bcrypt- oder Argon2-Hash entschlüsseln?

Nein. Es sind Einwegfunktionen. Das Passwort lässt sich nur finden, indem man Kandidaten rät und jeden hasht, und genau das machen diese Algorithmen absichtlich langsam.

Was ist das 72-Byte-Limit bei bcrypt?

bcrypt verwendet nur die ersten 72 Byte des Passworts. Alles danach beeinflusst den Hash nicht, sodass zwei lange Passwörter mit denselben ersten 72 Byte passende Hashes ergeben. Argon2 hat keine solche Grenze.

Welchen Cost-Faktor sollte ich für bcrypt verwenden?

Mindestens 10, und 12 ist ein gängiger Standard. Jede Erhöhung verdoppelt den Aufwand. Wählen Sie den höchsten Wert, bei dem der Login auf Ihrem Server noch ausreichend schnell ist.

Sind bcrypt-Hashes mit $2a$, $2b$ und $2y$ kompatibel?

Ja, für Passwörter bis 72 Byte ergeben sie denselben Hash. Die meisten Bibliotheken akzeptieren alle drei Präfixe, und dieses Tool prüft sie alle.

Warum dauert das Prüfen so lange wie das Hashen?

Prüfen bedeutet, das Passwort mit dem im Hash gespeicherten Salt und den Parametern erneut zu hashen und die Ergebnisse zu vergleichen; es kostet also genau denselben Aufwand. Genau das macht Raten teuer.

Wird das Passwort an einen Server gesendet?

Nein. bcrypt und Argon2 laufen per WebAssembly in Ihrem Browser. Nichts, was Sie eingeben, verlässt die Seite.

Bcrypt- und Argon2-Hash-Generator mit Prüfung

Passwort mit bcrypt oder Argon2 hashen oder gegen einen gespeicherten Hash prüfen

Dieser Passwort-Hash-Generator erzeugt bcrypt-Hashes (<code>$2b$</code>, Cost 4 bis 15) sowie Argon2id-, Argon2i- und Argon2d-Hashes im standardisierten PHC-String-Format, mit selbst gewähltem Speicher, Iterationen, Parallelität, Salt- und Ausgabelänge. Wechseln Sie zu <strong>Prüfen</strong>, um einen Hash aus Ihrer Datenbank einzufügen, Algorithmus und Parameter am Präfix erkennen zu lassen und zu testen, ob ein Passwort passt. Jeder Hash bekommt ein neues zufälliges Salt und zeigt, wie lange er auf Ihrem Gerät gedauert hat. Das Hashing läuft per WebAssembly in Ihrem Browser; das Passwort wird nie hochgeladen.

So erzeugen Sie einen bcrypt- oder Argon2-Hash

1Wählen Sie Hashen und dann den Algorithmus: Argon2id für neue Systeme, bcrypt passend zu einem bestehenden.
2Legen Sie den Cost fest: einen bcrypt-Cost-Faktor oder ein Argon2-Preset wie OWASP 19 MiB, t=2. Passen Sie Speicher, Iterationen und Parallelität von Hand an, wenn Sie eine Konfiguration nachbilden müssen.
3Geben Sie das Passwort ein und klicken Sie auf Passwort hashen. Der kodierte Hash, seine Bestandteile und die benötigte Zeit erscheinen darunter.
4Um einen Hash zu prüfen, wählen Sie Prüfen, fügen den gespeicherten Hash und das Passwort ein und klicken auf Prüfen.

Warum Passwörter einen langsamen Hash brauchen

Ein schneller Hash wie SHA-256 ist das falsche Werkzeug für Passwörter. Eine einzige Grafikkarte berechnet Milliarden SHA-256-Hashes pro Sekunde, sodass eine geleakte Tabelle mit SHA-256-Passwort-Hashes in diesem Tempo erraten werden kann. Passwort-Hash-Funktionen sind bewusst langsam und brauchen im Fall von Argon2 viel Speicher, damit jeder Rateversuch echte Zeit und Hardware kostet. Eine Einstellung, die auf Ihrem Server eine Viertelsekunde dauert, kostet einen Angreifer dieselbe Viertelsekunde für jeden Versuch und jeden Nutzer.

Jeder Hash enthält außerdem sein eigenes zufälliges Salt, sodass zwei Nutzer mit demselben Passwort unterschiedliche Hashes erhalten und vorberechnete Tabellen nutzlos sind. Salt und alle Parameter stehen im Hash-String selbst, deshalb kann eine Bibliothek ein Passwort allein anhand des Hashes prüfen.

Einen bcrypt-Hash lesen

Ein bcrypt-Hash wie $2b$12$R9h/cIPz0gi.URNNX3kh2OPST9/PgBkqquzi.Ss7KIUgO2t0jWMUW besteht aus vier Teilen: der Version 2b, dem Cost 12 (2¹² = 4.096 Runden Schlüsselexpansion), einem 22-stelligen Salt und einem 31-stelligen Hash, beide im eigenen Base64-Alphabet von bcrypt. Jede Stufe mehr Cost verdoppelt die Zeit.

$2a$ , $2b$ und $2y$ berechnen für Passwörter bis 72 Byte dasselbe Ergebnis; die Buchstaben kennzeichnen Korrekturen alter Implementierungsfehler. bcrypt liest nur die ersten 72 Byte eines Passworts und ignoriert den Rest, worauf dieses Tool hinweist — eine lange Passphrase oder eine in nicht-lateinischer Schrift, in der ein Zeichen zwei bis vier Byte belegt, erreicht diese Grenze schneller als gedacht.

Argon2id, Argon2i und Argon2d

Der PHC-String enthält alles, was zur Prüfung nötig ist: $argon2id$v=19$m=19456,t=2,p=1$<salt>$<hash> bedeutet Version 1.3, 19.456 KiB Speicher, 2 Durchläufe und 1 Lane, gefolgt von Salt und Hash in Base64 ohne Padding.

Argon2id: Die Mischform der beiden folgenden Varianten und die von RFC 9106 und OWASP empfohlene Variante für die Passwortspeicherung. Verwenden Sie sie, sofern nichts anderes zwingend ist.
Argon2i: Speicherzugriff unabhängig vom Passwort, dadurch resistent gegen Seitenkanalangriffe, aber schwächer gegen GPU-Cracking bei wenigen Durchläufen.
Argon2d: Speicherzugriff hängt vom Passwort ab: am stärksten gegen GPUs, aber anfällig für Seitenkanäle. Geeignet für Proof-of-Work, nicht für Server, die Logins prüfen.

Empfohlene Einstellungen

Argon2id: OWASP empfiehlt 19 MiB Speicher mit 2 Iterationen und Parallelität 1 oder einen gleichwertigen Kompromiss wie 47 MiB mit 1 Iteration oder 12 MiB mit 3. RFC 9106 schlägt 64 MiB, 3 Iterationen und 4 Lanes vor, wenn der Speicher reicht.
bcrypt: ein Cost von mindestens 10; 12 ist heute ein gängiger Standard. Wählen Sie den höchsten Cost, den Ihr Login-Endpoint verkraftet — etwa 250 ms pro Hash auf dem Server ist ein sinnvolles Ziel.
Salt: 16 zufällige Byte. Hash-Länge: 32 Byte sind reichlich.
Die hier gemessene Zeit gilt für Ihr Gerät mit WebAssembly, das meist langsamer ist als eine native Bibliothek auf einem Server. Messen Sie auf Ihrer Produktions-Hardware, bevor Sie einen Cost festlegen.

Wann Sie dieses Tool verwenden

Nutzen Sie es, um einen Hash für einen Seed-Nutzer oder eine Konfigurationsdatei zu erzeugen, um zu prüfen, ob ein Hash in Ihrer Datenbank wirklich zum vermuteten Passwort passt, oder um herauszufinden, mit welchen Parametern ein vorhandener Hash erstellt wurde. Ihre Anwendung sollte Passwörter bei der Registrierung mit ihrer eigenen Bibliothek hashen; sie sollte niemals Klartext-Passwörter zum Hashen an eine Website schicken. Ein starkes Passwort erstellen Sie mit dem Passwort-Generator; für Signaturen mit Schlüssel statt Passwortspeicherung siehe den HMAC-Generator.

Häufige Fragen

Sollte ich bcrypt oder Argon2 verwenden?: Argon2id für neue Systeme: Es hat die Password Hashing Competition gewonnen und ist memory-hard, was GPU- und ASIC-Cracking deutlich teurer macht. bcrypt ist weiterhin akzeptabel und sehr breit unterstützt; behalten Sie es, wenn Ihr Stack es bereits nutzt.
Warum ist der Hash für dasselbe Passwort jedes Mal anders?: Jeder Hash verwendet ein neues zufälliges Salt, daher ändert sich die Ausgabe jedes Mal. Das ist so gewollt. Um ein Passwort zu prüfen, verifizieren Sie es gegen den gespeicherten Hash, statt zwei frisch erzeugte Hashes zu vergleichen.
Kann man einen bcrypt- oder Argon2-Hash entschlüsseln?: Nein. Es sind Einwegfunktionen. Das Passwort lässt sich nur finden, indem man Kandidaten rät und jeden hasht, und genau das machen diese Algorithmen absichtlich langsam.
Was ist das 72-Byte-Limit bei bcrypt?: bcrypt verwendet nur die ersten 72 Byte des Passworts. Alles danach beeinflusst den Hash nicht, sodass zwei lange Passwörter mit denselben ersten 72 Byte passende Hashes ergeben. Argon2 hat keine solche Grenze.
Welchen Cost-Faktor sollte ich für bcrypt verwenden?: Mindestens 10, und 12 ist ein gängiger Standard. Jede Erhöhung verdoppelt den Aufwand. Wählen Sie den höchsten Wert, bei dem der Login auf Ihrem Server noch ausreichend schnell ist.
Sind bcrypt-Hashes mit $2a$, $2b$ und $2y$ kompatibel?: Ja, für Passwörter bis 72 Byte ergeben sie denselben Hash. Die meisten Bibliotheken akzeptieren alle drei Präfixe, und dieses Tool prüft sie alle.
Warum dauert das Prüfen so lange wie das Hashen?: Prüfen bedeutet, das Passwort mit dem im Hash gespeicherten Salt und den Parametern erneut zu hashen und die Ergebnisse zu vergleichen; es kostet also genau denselben Aufwand. Genau das macht Raten teuer.
Wird das Passwort an einen Server gesendet?: Nein. bcrypt und Argon2 laufen per WebAssembly in Ihrem Browser. Nichts, was Sie eingeben, verlässt die Seite.