Bcrypt-Hash erzeugen und prüfen

Über dieses Tool

Warum bcrypt absichtlich langsam ist

Passwortdatenbanken werden gestohlen, und wer eine besitzt, kann Passwörter offline erraten, so schnell es seine Hardware erlaubt. Allzweck-Hashes wie SHA-256 sind auf Geschwindigkeit ausgelegt, sodass eine einzige Grafikkarte Milliarden Kandidaten pro Sekunde durchprobiert. bcrypt, 1999 von Niels Provos und David Mazières veröffentlicht, baut auf dem aufwendigen Key-Setup der Blowfish-Chiffre auf und wiederholt es eine konfigurierbare Anzahl von Malen, was jeden Rateversuch teuer macht.

Jeder Hash enthält außerdem sein eigenes zufälliges 16-Byte-Salt. Zwei Benutzer mit demselben Passwort erhalten unterschiedliche Hashes, und eine für ein Salt vorab berechnete Tabelle nützt beim nächsten nichts. Ein bcrypt-Hash lässt sich nicht entschlüsseln. Der praktische Angriff ist das Raten, deshalb fällt ein schwaches Passwort unabhängig vom Kostenfaktor trotzdem schnell.

Was der Kostenfaktor bedeutet und wie Sie ihn wählen

Der Kostenfaktor ist der Logarithmus zur Basis 2 der Anzahl der Key-Setup-Runden: Kostenfaktor 10 sind 1.024 Runden, Kostenfaktor 12 sind 4.096. Jede Erhöhung um eins verdoppelt die Zeit für eine Anmeldung und für jeden Rateversuch eines Angreifers. Der Kostenfaktor steht im Hash, Sie können ihn also später erhöhen: Alte Hashes lassen sich weiterhin verifizieren, und Sie können ein Passwort mit dem neuen Kostenfaktor neu hashen, wenn sich sein Besitzer das nächste Mal anmeldet.

Wählen Sie den höchsten Kostenfaktor, den sich Ihr Server für eine Anmeldung leisten kann, und nicht weniger als 10, das Minimum, das das OWASP Password Storage Cheat Sheet für bcrypt nennt. Die hier angezeigte Zeit wird mit WebAssembly in Ihrem Browser gemessen, was meist langsamer ist als nativer Code auf einem Server. Messen Sie also auf dem Rechner, der das Hashen übernehmen wird. Aus diesem Grund endet dieses Tool bei Kostenfaktor 14.

Die 72-Byte-Grenze

bcrypt verwendet höchstens 72 Bytes des Passworts. Die Grenze gilt für Bytes, nicht für Zeichen: In UTF-8 belegt ein Buchstabe mit Akzent wie é zwei Bytes, die meisten CJK-Zeichen drei und die meisten Emojis vier oder mehr. Viele Bibliotheken schneiden längere Eingaben stillschweigend ab, sodass zwei lange Passwörter mit denselben ersten 72 Bytes gegen denselben Hash verifiziert werden. Die hier verwendete Go-Implementierung verweigert das Hashen längerer Eingaben, und dieses Tool weist Sie darauf hin, wenn das passiert.

Wenn Ihre Benutzer längere Passwörter wählen dürfen, ist die einfache Lösung, diese bei der Registrierung mit einer klaren Meldung abzulehnen. Ein verbreiteter Workaround hasht das Passwort zuerst mit SHA-256 und übergibt bcrypt den Base64- oder Hex-Text dieses Hashwerts. Er darf nicht die rohen Bytes des Hashwerts übergeben, weil manche Implementierungen bei einem Nullbyte aufhören zu lesen, und das OWASP Cheat Sheet rät von dieser Art des Pre-Hashings ab, weil sie einen Angriff namens Password Shucking ermöglicht. Für ein neues System empfiehlt OWASP Argon2id vor bcrypt, und Argon2id hat keine 72-Byte-Grenze.

Einen Hash lesen, und wie dieses Tool arbeitet

Ein bcrypt-Hash hat 60 Zeichen: ein Versionspräfix wie $2b$, einen zweistelligen Kostenfaktor und $, 22 Zeichen Salt und 31 Zeichen Hashwert, beide im eigenen Base64-Alphabet von bcrypt (./A-Za-z0-9). Alles, was zum Prüfen eines Passworts nötig ist, steht in diesem einen String, es gibt also keine separate Salt-Spalte zu speichern.

Hashen und Prüfen übernimmt das Go-Paket golang.org/x/crypto/bcrypt, kompiliert zu WebAssembly und ausgeführt in einem Hintergrund-Thread Ihres Browsers. Passwörter und Hashes werden nirgendwohin gesendet und nicht gespeichert. Die Seite ist für Testdaten, Fixtures und das Prüfen eines vorhandenen Hashs gedacht: Die Passwörter echter Benutzer sollte Ihre Anwendung auf Ihrem Server hashen.