bcrypt Hash-Generator
Kostenloses Online-bcrypt-Hash-Generator-Tool. 100% lokale Verarbeitung – Ihre Daten verlassen Ihr Gerät nie.
Ergebnis wird hier angezeigt...
Eingabe → Hash berechnen
Usage Guide
Über bcrypt
bcrypt ist eine Passwort-Hash-Funktion, die 1999 von Niels Provos und David Mazières auf Basis des Blowfish-Verschlüsselungsalgorithmus entwickelt wurde. Sie wurde bewusst langsam und rechenintensiv konzipiert, um Brute-Force-Angriffe unpraktikabel zu machen. bcrypt ist einer der am weitesten verbreiteten Passwort-Hashing-Algorithmen der Welt und wird nativ von Frameworks wie Rails, Django, Laravel und Node.js (bcryptjs) unterstützt. Jeder bcrypt-Hash enthält einen zufälligen Salt-Wert und den Kostenfaktor, sodass der Hash für die Verifizierung vollständig eigenständig ist.
Verwendungsschritte
Dieses Tool unterstützt zwei Operationen: Passwort hashen (Verschlüsseln) und Passwort gegen einen Hash verifizieren (Entschlüsseln):
Algorithmuseigenschaften
bcrypt verfügt über mehrere Eigenschaften, die es für die Passwortspeicherung geeignet machen:
Leitfaden für den Kostenfaktor
Die Wahl des richtigen Kostenfaktors balanciert Sicherheit gegen Server-Performance:
FAQ
Q: Was ist das Ausgabeformat von bcrypt?
A: Ein bcrypt-Hash ist immer genau 60 Zeichen lang und sieht so aus: $2b$12$LQv3c1yqBWVHxkd0LHAkCOYz6TtxMQJqhN8/lewdBdXyXu2zXpOme.
Aufschlüsselung:$2b$: bcrypt-Versionskennung.12$: Der Kostenfaktor.
Nächste 22 Zeichen: Base64-kodierter 128-Bit-Zufalls-Salt.
Letzte 31 Zeichen: Base64-kodierter 184-Bit abgeleiteter Hash.
Schlüsseleigenschaft: Alle Parameter sind im String eingebettet — kein zusätzlicher Speicher ist erforderlich, um ein Passwort später zu verifizieren.
Q: Wie verhält sich bcrypt im Vergleich zu Argon2?
A: bcrypt (1999): rechenintensiv, ~4 KB Speicher, moderate GPU-Resistenz, universell unterstützt. Argon2 (2015): speicherintensiv (konfigurierbar, Standard 64 MB), viel stärkere ASIC/GPU-Resistenz, von OWASP und NIST bevorzugt. Wann bcrypt verwenden: Pflege eines bestehenden Systems oder wenn Argon2 noch nicht verfügbar ist. Wann Argon2 verwenden: Alle neuen Projekte.
Q: Warum kann bcrypt nicht zum Hashen von Dateien oder großen Datenmengen verwendet werden?
A: bcrypt hat ein 72-Byte-Eingabelimit. Zeichen nach dem 72. Byte werden stillschweigend ignoriert. Verwenden Sie für Datei-Integrität SHA-256 oder SHA-512. bcrypt ist zweckgebunden für kurze, manuell eingegebene Passwörter.
Q: Ist bcrypt sicher, wenn meine Datenbank kompromittiert wird?
A: Ja — ein bcrypt-Hash ist einwegig. Bei cost=12 kann ein einzelner CPU-Kern etwa 2–5 Hashes pro Sekunde versuchen, was erschöpfende Angriffe auf starke Passwörter praktisch unmöglich macht. bcrypt schützt jedoch keine schwachen Passwörter — erzwingen Sie immer eine Mindest-Passwortstärken-Richtlinie.
Q: Welchen Kostenfaktor sollte ich in der Produktion verwenden?
A: OWASP 2023 Empfehlung: cost=12 als Baseline. Führen Sie Benchmarks auf Ihrem Produktionsserver durch und wählen Sie den höchsten Kostenfaktor, der das Hashing unter 500 ms hält. Gehen Sie niemals unter cost=10. Überprüfen Sie alle 2–3 Jahre, wenn die Hardware besser wird.
Q: Kann bcrypt für API-Schlüssel oder Token-Speicherung verwendet werden?
A: Ja, mit Einschränkungen. bcrypt eignet sich zum Hashen von API-Schlüsseln und Tokens, die kürzer als 72 Bytes sind und selten verifiziert werden. Für hochfrequente Verifizierung verwenden Sie stattdessen einen schnellen SHA-256 + Salt-Ansatz.
Use Cases
Empfohlen: Benutzerpasswort-Speicherung
Dies ist bcrypts primärer Anwendungsfall. Mit bcrypt hashen (cost ≥ 12) und den 60-Zeichen-String speichern. Beim Login bcrypt-Verifizierung durchführen. bcrypt wird out-of-the-box in Rails (has_secure_password), Django, Laravel und Node.js (bcryptjs) unterstützt.
Empfohlen: Legacy-System-Kompatibilität
Bei Systemen, die Millionen von bcrypt-Hashes speichern, bcrypt weiterhin verwenden und den Kostenfaktor mit der Hardware erhöhen. Neue Benutzer können transparent auf Argon2id aktualisieren, während bcrypt-Hashes (erkennbar am $2b$-Präfix) weiterhin korrekt verifiziert werden.
- ✅ bcrypt für bestehende Hashes beibehalten — keine erzwungene Migration erforderlich
- ✅ Argon2id schrittweise für neue und aktualisierte Passwörter einführen
- ✅ Hash-Präfix-Erkennung ($2b$ vs $argon2id$) zur Routing-Verifizierung verwenden
- 💡 Den verwendeten Algorithmus pro Benutzer protokollieren, um den Migrationsfortschritt zu verfolgen
Akzeptabel: API-Schlüssel-Hashing
bcrypt kann API-Schlüssel vor der Datenbankspeicherung hashen. Für die Verifizierung pro Anfrage in großem Maßstab sollten Sie ein schnelles HMAC-SHA256-Schema oder einen SHA-256 Hash des Schlüssels bevorzugen.
- ✅ bcrypt (cost=10–12, gut für niederfrequente Verifizierung)
- ✅ SHA-256 + Salt (schneller, geeignet für hochentropische Schlüssel)
- ✅ HMAC-SHA256 (für Token-Signierung pro Anfrage)
- 💡 Hash-Präfix (erste 8 Zeichen) als Datenbankindex für schnelle Suche verwenden
Nicht empfohlen: Datei- oder Datenverschlüsselung
bcrypt ist eine Einweg-Hash-Funktion, kein Verschlüsselungsalgorithmus. Es kann keine Dateien verschlüsseln. Außerdem macht bcrypts 72-Byte-Eingabelimit es ungeeignet zum Hashen von Dateiinhalten. Für Dateiverschlüsselung verwenden Sie eine symmetrische Verschlüsselung (z.B. AES-256-GCM).
- ❌ bcrypt nicht für Dateiverschlüsselung verwenden (nicht umkehrbar)
- ❌ Daten länger als 72 Bytes nicht mit bcrypt hashen
- ✅ AES-256-GCM für symmetrische Dateiverschlüsselung verwenden
- ✅ Argon2id oder scrypt für passwortbasierte Schlüsselableitung verwenden
Nicht empfohlen: Allgemeines Daten-Hashing
bcrypt ist zu langsam für allgemeine Datenintegritätsprüfungen. Verwenden Sie SHA-256 oder SHA-512 für Integritätsverifizierung.
- ❌ bcrypt nicht für Datenintegritätsprüfungen oder Content-Hashing verwenden
- ✅ SHA-256 (allgemeines Integritäts-Hashing)
- ✅ BLAKE2b (hochgeschwindigkeits kryptografisches Hashing)
- ✅ SHA-3 / SHA-512 (höherer Sicherheitsspielraum)
Nicht empfohlen: Hochfrequente Authentifizierung
bcrypt ist darauf ausgelegt, langsam zu sein (~200–500 ms bei cost=12). Das Ausführen bei jeder API-Anfrage würde Ihren Server zum Erliegen bringen. Verwenden Sie bcrypt nur einmal beim Login — dann ein signiertes JWT für nachfolgende Anfragen ausstellen.
- ❌ bcrypt nicht bei jeder API-Anfrage ausführen
- ✅ JWT + HMAC-SHA256 (zustandslose, schnelle Authentifizierung pro Anfrage)
- ✅ Session + Cookie (traditionelles serverseitiges Session-Management)
- ✅ OAuth 2.0 / OpenID Connect (föderierte Identität, tokenbasiert)
Best-Practice-Zusammenfassung
- bcrypt (cost ≥ 12) für Benutzerpasswort-Speicherung in bestehenden Systemen verwenden. Für neue Projekte Argon2id bevorzugen.
- bcrypt niemals für allgemeines Daten-Hashing, Dateiverschlüsselung oder Daten größer als 72 Bytes verwenden.
- Auf Produktionshardware benchmarken und 200–500 ms pro Hash anstreben. Den Kostenfaktor alle 2–3 Jahre erhöhen.
- Für hochfrequente Auth-Szenarien bcrypt nur beim Login verwenden, dann JWT oder Session-Tokens ausstellen.
- Schrittweise Migration von bcrypt zu Argon2id: bcrypt für bestehende Hashes beibehalten, Argon2id für neue Passwörter verwenden.