Bcrypt-Passwort-Hash-Generator

Diese seltsame Zeichenfolge lesen, die er Ihnen liefert

Ein Bcrypt-Hash sieht aus wie Zeichenrauschen, hat aber eine feste Anatomie, die sich zu kennen lohnt. Er beginnt mit einer Versionskennung wie $2a$ oder $2b$, gefolgt vom gewählten Kostenfaktor, dann zweiundzwanzig Zeichen des zufälligen Salts und schließlich den einunddreißig Zeichen des eigentlichen Hashes. Alles, was eine Prüfung braucht, reist innerhalb dieser einen Zeichenfolge — deshalb passt das Ganze in eine einzige Datenbankspalte, und deshalb ergibt das Erzeugen eines Hashes für dasselbe Passwort zweimal zwei unterschiedliche Zeichenfolgen, die trotzdem beide gültig sind. Der Salt unterscheidet sich jedes Mal, also unterscheidet sich auch die Ausgabe jedes Mal; wenn Ihr Backend später einen Login prüft, liest es den Salt aus der gespeicherten Zeichenfolge zurück, hasht den Versuch damit und vergleicht das Ergebnis.

Wo Sie diese Seite tatsächlich einsetzen würden

Meist findet Bcrypt-Hashing innerhalb Ihrer Anwendung statt, nicht in einem Browser — aber es gibt Momente, in denen ein handgemachter Hash genau das ist, was Sie brauchen. Eine Testdatenbank mit Konten befüllen, deren Passwörter Sie kennen. Ein ausgesperrtes Admin-Konto retten, indem Sie einen frischen Hash direkt in die Benutzertabelle schreiben. Prüfen, welche Form von Zeichenfolge eine Bibliothek erzeugen wird, bevor Sie die Spalte dafür dimensionieren. In all diesen Fällen fügen Sie ein Passwort ein, kopieren den Hash und setzen ihn dort ein, wo Ihr Login-Code einen erwartet. Eine Sache, die Sie nie tun sollten: Hashes als Zeichenketten in Ihrem eigenen Code vergleichen. Wegen des Salts erzeugt dasselbe Passwort unterschiedliche Hashes — die Verifizierung muss über die Vergleichsfunktion Ihrer Bibliothek laufen, die weiß, wie sie den Salt zurücklesen kann.

Einen Kostenfaktor wählen, mit dem Sie leben können

Jede Stufe des Kostenfaktors verdoppelt den Aufwand, für Sie ebenso wie für einen Angreifer. Acht ist schnell und am besten der Kompatibilität mit Altsystemen vorbehalten; zehn, die Voreinstellung hier, ist die gängige Wahl für den Produktivbetrieb; zwölf verschafft Komfort, wenn Logins selten sind; vierzehn braucht selbst zum Erzeugen Sekunden. Ein fairer Hinweis zur Geschwindigkeit: Diese Seite läuft mit einer reinen JavaScript-Implementierung, die langsamer ist als der native Code auf Ihrem Server — betrachten Sie die hier gefühlte Verzögerung also als Obergrenze und nicht als Benchmark; messen Sie auf der Maschine, die die Logins tatsächlich verarbeiten wird. Und weil ein Hash nur so gut ist wie das, was hineinfließt: Der Passwort-Generator liefert eine starke Eingabe, während alles, was kein Passwort ist — Dateien, Dokumente, reiner Text — stattdessen zum SHA-Hash-Generator gehört.

Warum Bcrypt statt eines einfachen Hashes

Ein einfacher SHA-Hash eines Passworts lässt sich auf moderner Hardware schnell per Brute-Force knacken. Bcrypt ist bewusst langsam — der Kostenfaktor legt genau fest, wie langsam — und salzt automatisch, sodass dasselbe Passwort niemals zweimal denselben gespeicherten Hash erzeugt. Deshalb ist es serverseitig weiterhin eine Standardwahl zur Speicherung von Passwörtern.