bcrypt Hash & Verifikation
KryptoHashen Sie ein Passwort mit bcrypt (adaptiver Cost), oder verifizieren Sie einen Klartext gegen einen vorhandenen $2a$ / $2b$-Hash. Einstellbarer Cost, kalibrierte Zeitmessung — alles in Ihrem Browser.
Remote-URLs werden nicht abgerufen; fügen Sie Ihr JSON direkt ein.
⚠ Höherer Cost ist langsamer und sicherer
Auf dieser Seite
Was ist bcrypt?#
bcrypt ist eine Passwort-Hash-Funktion, die absichtlich langsam gebaut ist. Wo ein schneller Hash wie SHA-256 darauf ausgelegt ist, Megabytes pro Sekunde zu durchsatzten, ist bcrypt darauf ausgelegt, pro einzelner Vermutung echte Zeit zu kosten — sodass ein Angreifer, der eine Datenbank von Passwort-Hashes stiehlt, nicht billig Milliarden Vermutungen ausprobieren kann. Es ist die Standardantwort auf „wie sollte ich Benutzerpasswörter speichern“: hashen Sie sie mit bcrypt, nicht mit einem bloßen SHA-256.
Zwei Dinge machen bcrypt für diesen Job geeignet. Erstens hat es einen einstellbaren Cost-Faktor, der die Arbeit exponentiell skaliert — den Cost um 1 anheben verdoppelt in etwa die Zeit pro Hash, sodass Hardware durch Drehen eines Knopfs überholt werden kann. Zweitens backt es einen zufälligen Salt in jeden Hash ein, sodass identische Passwörter zu völlig verschiedenen Werten hashen und eine für eine Datenbank vorberechnete Tabelle gegen eine andere nutzlos ist. Salt und Cost werden beide im Ausgabestring getragen, sodass die Verifikation nichts über das Passwort und den Hash hinaus braucht.
Diese Seite macht beide Operationen: ein Passwort zu einem bcrypt-String hashen und ein Passwort gegen einen vorhandenen Hash verifizieren. Um die Seite ansprechbar zu halten, wird das Hashen bei Cost 12 oder höher an einen Web Worker ausgelagert, sodass die schwere Berechnung die Oberfläche niemals einfriert.
Verwendung#
- Wählen Sie einen Modus: Hashen (einen bcrypt-String aus einem Passwort erzeugen) oder Verifizieren (ein Passwort gegen einen vorhandenen Hash prüfen).
- Tippen Sie das Passwort. Klicken Sie auf das Augensymbol, um es beim Tippen zu zeigen; es ist standardmäßig maskiert. UTF-8 wird akzeptiert, einschließlich Emoji und nicht-lateinischer Schriften.
- Setzen Sie im Modus Hashen den Cost-Faktor-Schieber (4–14, Standard 12). Höher ist langsamer und stärker. Eine Warnung erscheint, sobald der Cost hoch genug ist, merkbare Zeit zu kosten.
- Fügen Sie im Modus Verifizieren den vorhandenen Hash in das Feld ein, das erscheint. Der Cost wird automatisch aus dem Hash selbst gelesen — Sie setzen ihn nicht.
- Klicken Sie die Hauptschaltfläche. Im Modus Hashen ist die Ausgabe der bcrypt-String; im Modus Verifizieren ist die Ausgabe ein klares Match-/No-Match-Urteil, plus einer Verstrichene-Zeit-Anzeige, die Ihnen hilft, den Cost auf Ihrer eigenen Hardware einzuschätzen.
Eckpunkte#
- Tunbarer Cost, 4–14. Der Standard 12 ist die moderne Empfehlung; jede Stufe verdoppelt in etwa die Arbeit, sodass Sie mit der Jahre über schnellerer Hardware Schritt halten können.
- Worker-Auslagerung bei hohem Cost. Cost 12 und höher läuft in einem Web Worker, sodass die Seite ansprechbar bleibt; falls Worker blockiert sind, fällt er transparent auf den Haupt-Thread mit demselben Ergebnis zurück.
- Eingebauter Salt. Jeder Hash erhält einen frischen zufälligen Salt, der in die Ausgabe kodiert wird, sodass dasselbe Passwort niemals zweimal zu demselben String hasht.
- Verifikation mit automatischem Cost. Der Cost-Faktor wird aus dem Hash geparst, den Sie einfügen, sodass es keinen Mismatch gibt zwischen wie ein Passwort gehasht wurde und wie es geprüft wird.
- Kein Upload. Hashen und Verifikation passieren lokal; das Passwort verlässt niemals die Seite.
Konkretes Beispiel#
Unten steht ein echter Hash von hunter2 bei Cost 12, erzeugt von genau dieser Seite. Weil der Salt frisch zufällig ist, wird das Hashen von hunter2 erneut einen anderen String liefern — aber dieser hier ist echt und verifizierbar: Fügen Sie ihn in den Modus Verifizieren ein, tippen Sie hunter2, und das Urteil lautet match.
$2b$12$DG/IWIDBmJlywamLdGno2.guEH5lGnQ1OTULdIGN8BH1vqiLIGzjy
Feld für Feld gelesen:
$2b$— die bcrypt-Variante (bcryptjs emittiert$2b$; die Verifikation akzeptiert auch$2a$,$2x$,$2y$).12— der Cost-Faktor, was2^12Schlüsselexpansions-Runden bedeutet.- die nächsten 22 Zeichen — der zufällige Salt.
- die letzten 31 Zeichen — der abgeleitete Hash.
Wechseln Sie zu Verifizieren, legen Sie den Hash oben ins Feld für den vorhandenen Hash, tippen Sie hunter2, und das Urteil lautet match. Tippen Sie stattdessen Hunter2, so lautet es no match — bcrypt ist groß-/kleinschreibungssensitiv, und ein einziges falsches Zeichen kippt das Ergebnis. Die angezeigte verstrichene Zeit ist der echte Cost einer einzigen Verifikation bei Cost 12 auf Ihrer Maschine.
FAQ#
Welchen Cost soll ich wählen?#
12 ist ein solider Standard für neue Systeme heute — es dauert auf typischer Hardware grob ein paar hundert Millisekunden, was für ein echtes Login schmerzfrei, für Massenraten aber schmerzhaft ist. Heben Sie es für hochwertige Ziele auf 13 oder 14, wo ein etwas langsameres Login akzeptabel ist. Die Kernregel ist, den Cost über die Jahre nach oben neu zu kalibrieren, während die Hardware besser wird, weil bcrypts Cost exponentiell skaliert: jede Erhöhung um 1 verdoppelt in etwa die Zeit.
Warum liefert zweimaliges Hashen desselben Passworts verschiedene Ergebnisse?#
Weil bcrypt jedes Mal einen frischen zufälligen Salt erzeugt und ihn in die Ausgabe einbettet. Die zwei Hashes ähneln sich gar nicht, und doch verifizieren beide gegen dasselbe Passwort. Das ist der ganze Sinn des Salten — es stoppt einen Angreifer daran, wiederholte Passwörter zu erkennen oder eine vorberechnete Tabelle wiederzuverwenden.
Kann ich einen Hash verifizieren, der woanders erzeugt wurde?#
Ja, solange es ein wohlgeformter bcrypt-String ist ($2a$, $2b$, $2x$ oder $2y$). Fügen Sie ihn im Modus Verifizieren ins Feld für den vorhandenen Hash; das Werkzeug liest Cost und Salt aus dem Hash selbst. Aus Nodes bcrypt, PHPs password_hash oder Pythons passlib exportierte Hashes funktionieren hier alle.
Ist bcrypt besser als SHA-256 für Passwörter?#
Für das Speichern von Login-Passwörtern: ja — nachdrücklich. SHA-256 ist schnell, was genau die falsche Eigenschaft für einen gespeicherten Passwort-Hash ist: Ein Angreifer mit dem Hash kann Milliarden Vermutungen pro Sekunde auf einer GPU ausprobieren. bcrypt ist absichtlich langsam und gesalzen, was Passwortspeicherung verlangt. Verwenden Sie SHA-256 für Integrität und Signaturen; verwenden Sie bcrypt (oder seine Verwandten Argon2/scrypt) für menschliche Passwörter.