Bcrypt Generator Online — Kostenlos, 100% Clientseitig, Ohne Anmeldung
Generiere und überprüfe Bcrypt-Hashes vollständig im Browser — kein Server, keine gespeicherten Daten. Die gesamte Verarbeitung erfolgt lokal mit bcryptjs, einer reinen JavaScript-Implementierung von Bcrypt. Öffne DevTools, beobachte den leeren Network-Tab und überzeuge dich selbst: Dein Passwort verlässt niemals deinen Rechner.
Dieses Tool geht über den einfachen Hash-und-Verify-Ablauf hinaus. Miss die tatsächliche Hashing-Zeit auf deiner Hardware für jeden Kostenfaktor, analysiere jeden bestehenden Bcrypt-Hash, um seine Struktur zu verstehen, und kopiere ausführbaren Code für acht Programmiersprachen.
So Verwendest Du den Bcrypt Generator
Einen Bcrypt-Hash aus einem Passwort zu erzeugen dauert weniger als fünf Sekunden:
- Füge dein Passwort ein oder tippe es in das Feld "Input Password" — das Badge "CLIENT-SIDE SECURE" bestätigt, dass keine Netzwerkanfrage gestellt wird.
- Passe den Kostenfaktor an mit dem Slider (4–18). Kostenfaktor 12 ist der OWASP-empfohlene Standard; höhere Werte erhöhen die Sicherheit, aber auch die Hash-Zeit.
- Klicke auf "Generate Bcrypt Hash" — der Hash erscheint sofort, zusammen mit der genauen Zeit, die es auf deinem aktuellen Gerät gedauert hat.
- Kopiere den Hash mit dem Kopierschaltfläche oder drücke
Shift+Enteraußerhalb der Eingabefelder.
Um ein Passwort gegen einen bestehenden Hash zu überprüfen, wechsle zur Registerkarte Verify Hash, gib beide Werte ein und klicke auf "Verify Match".
Bcrypt-Hash-Beispiele
Bcrypt erzeugt immer einen String mit genau 60 Zeichen. Aufgrund des zufälligen Salts produziert das zweimalige Hashen desselben Passworts immer unterschiedliche Hashes — aber beide werden korrekt gegen das ursprüngliche Passwort verifiziert.
Beispiel — Kostenfaktor 12 (OWASP-Standard):
Eingabe: meingeheimespasswort
Ausgabe: $2b$12$nOUIs5kJ7naTuTFkBy1veuK0kSxUFXfuaOKdOKf9xYT0KKIGSJwFa
Beispiel — gleiches Passwort, unterschiedliche Hashes:
Eingabe: meingeheimespasswort (zweimal mit Kostenfaktor 12 gehashed)
Hash 1: $2b$12$nOUIs5kJ7naTuTFkBy1veu...
Hash 2: $2b$12$aBcDeFgHiJkLmNoPqRsTuv... ← anderes Salt, beide gültig
Randfall — 72-Byte-Begrenzung:
Eingabe 1: [72 'a'-Zeichen]
Eingabe 2: [100 'a'-Zeichen]
Ergebnis: beide erzeugen äquivalente Hashes — Bytes über 72 werden stillschweigend ignoriert
Bcrypt-Hash-Format — Was Jeder Teil Bedeutet
Jeder Bcrypt-Hash hat exakt dieselbe Struktur. Für $2b$12$nOUIs5kJ7naTuTFkBy1veuK0kSxUFXfuaOKdOKf9xYT0KKIGSJwFa:
| Segment | Wert | Bedeutung |
|---|---|---|
| Version | $2b$ |
Algorithmusversion — verwende immer $2b$ für neue Implementierungen |
| Kostenfaktor | 12 |
2¹² = 4.096 Iterationen |
| Salt | nOUIs5kJ7naTuTFkBy1veu |
22 Zeichen, base64-kodiertes 128-Bit-Zufallssalt |
| Hash | K0kSxUFXfuaOKdOKf9xYT0KKIGSJwFa |
31 Zeichen, die eigentliche Prüfsumme der Eingabe |
Die Versionspräfixe: $2a$ ist die ursprüngliche Spezifikation mit einem Randfallbug für Hochbit-Zeichen; $2b$ ist der korrigierte aktuelle Standard; $2y$ ist PHPs Äquivalent zu $2b$. Verwende immer $2b$ für neuen Code.
Was Ist Bcrypt und Warum Ist Es Wichtig?
Bcrypt ist eine Passwort-Hashing-Funktion, die 1999 von Niels Provos und David Mazières entwickelt wurde, basierend auf dem Blowfish-Chiffre. Im Gegensatz zu MD5 oder SHA-256 — die schnelle Allzweck-Funktionen sind — ist Bcrypt absichtlich langsam. Sein Kostenfaktor ist einstellbar, sodass der Rechenaufwand erhöht werden kann, wenn Hardware schneller wird, und Brute-Force-Angriffe wirtschaftlich unrentabel bleiben.
Bcrypt generiert und bettet automatisch ein einzigartiges Zufallssalt in jeden Hash ein. Dies verhindert Rainbow-Table-Angriffe, bei denen Angreifer vorberechnete Nachschlagetabellen verwenden, um häufige Hashes umzukehren. Selbst wenn zwei Benutzer identische Passwörter haben, werden ihre Bcrypt-Hashes unterschiedlich sein.
Häufige Anwendungsfälle
- Benutzer-Authentifizierungssysteme: Passwörter vor der Speicherung in einer Datenbank hashen. Beim Login führt
bcrypt.compare()denselben Algorithmus mit dem gespeicherten Salt aus und bestätigt eine Übereinstimmung in konstanter Zeit, was Timing-Angriffe verhindert. - Migration von schwächeren Algorithmen: Passwörter schrittweise von MD5/SHA-1 auf Bcrypt umhash. Bei erfolgreichem Login mit dem alten Hash das Passwort verifizieren und sofort durch einen Bcrypt-Hash ersetzen.
- Kostenfaktor-Kalibrierung: Den lokalen Benchmark auf der Hardware deines Produktionsservers ausführen, um den höchsten Kostenfaktor zu finden, der die Login-Latenz unter deiner UX-Schwelle hält (typischerweise 300ms–1s).
- Sicherheitsaudits: Einen bestehenden Hash in den Parser einfügen, um zu überprüfen, ob er
$2b$verwendet, den Kostenfaktor gegen OWASP-Mindestanforderungen zu bestätigen, und korrekte Salt- und Hash-Längen zu prüfen.
Häufige Fehler mit Bcrypt
- Kostenfaktor 4–8 in der Produktion verwenden: Diese Werte werden in unter 1ms abgeschlossen und bieten keinen bedeutenden Brute-Force-Schutz. Kostenfaktor 4 existiert nur für Unit-Tests. Verwende mindestens Kostenfaktor 10, standardmäßig Kostenfaktor 12.
- Bereits gehashte Hashes erneut hashen: Bcrypt auf einen Bcrypt-Hash auszuführen erzeugt eine doppelt kodierte Zeichenkette, die nie verifiziert werden kann. Immer nur den ursprünglichen Klartext hashen.
- Die 72-Byte-Begrenzung ignorieren: Bcrypt verarbeitet nur die ersten 72 Bytes einer Eingabe. Wenn deine Anwendung Passwörter über ~72 ASCII-Zeichen erlaubt, erwäge Pre-Hashing mit SHA-256 vor Bcrypt oder wechsle zu Argon2id, das keine solche Begrenzung hat.
Häufig Gestellte Fragen
Welchen Kostenfaktor sollte ich für Bcrypt verwenden?
OWASP empfiehlt Kostenfaktor 12 als Ausgangspunkt, mit dem Ziel von ungefähr 250ms pro Hash auf moderner Hardware. Der richtige Wert hängt von deinem spezifischen Server ab — nutze den lokalen Benchmark auf dieser Seite, um die tatsächliche Zeit zu messen, und wähle dann den höchsten Faktor, der die Authentifizierungslatenz unter deiner UX-Schwelle hält.
Kann ein Bcrypt-Hash umgekehrt oder entschlüsselt werden?
Nein. Bcrypt ist eine Einwegfunktion — es gibt keine mathematische Methode, das ursprüngliche Passwort aus einem Hash abzuleiten. Der einzige Ansatz ist Brute Force: Passwörter erraten, jedes mit dem gespeicherten Salt hashen und vergleichen. Die hohe Iterationszahl macht dies rechnerisch teuer.
Was ist der Unterschied zwischen den Präfixen $2a$ und $2b$ bei Bcrypt?
$2a$ ist die ursprüngliche Spezifikation von 1999. Einige Implementierungen hatten einen Randfallbug beim Hashen von Passwörtern mit Zeichen über dem 8-Bit-Bereich. $2b$ korrigiert diesen Bug und ist der aktuelle Standard. $2y$ ist eine PHP-spezifische Variante, mathematisch äquivalent zu $2b$. Für jede neue Implementierung $2b$ verwenden.
Unterstützt Bcrypt Passwörter mit mehr als 72 Zeichen?
Bcrypt verarbeitet nur die ersten 72 Bytes einer Eingabe. Zeichen über 72 Bytes werden stillschweigend ignoriert. Wenn Benutzer Passwörter länger als ~70 Zeichen erstellen können, sollte man Pre-Hashing mit SHA-256 vor Bcrypt in Betracht ziehen oder zu Argon2id wechseln, das keine Längenbegrenzung hat.
Sollte ich für ein neues Projekt Bcrypt oder Argon2id verwenden?
OWASP empfiehlt jetzt Argon2id als erste Wahl für neue Systeme — es ist memory-hard (widerstandsfähiger gegen GPU- und ASIC-Angriffe), hat keine Passwortlängenbegrenzung und gewann den Password Hashing Competition 2015. Bcrypt bleibt eine solide, bewährte Wahl für Systeme, die es bereits verwenden, mit Kostenfaktor 12 oder höher.
Ressourcen
- OWASP Password Storage Cheat Sheet — Maßgebliche Anleitung zu empfohlenen Algorithmen, Kostenfaktoren und Migrationsstrategien.
- bcryptjs auf GitHub — Die reine JavaScript-Bibliothek, die dieses Tool antreibt — keine nativen Abhängigkeiten, funktioniert in jedem Browser.