Bcrypt Tool
Bcrypt Tool
Echte bcrypt-Hashes mit bcryptjs (v3) erstellen und verifizieren. 100% lokal im Browser – kompatibel mit Node.js, PHP und anderen Systemen.
Echtes Bcrypt: Dieses Tool verwendet bcryptjs v3.0.3 – die reale, in Produktion eingesetzte bcrypt-Implementierung. Die Hashes sind kompatibel mit Node.js, PHP, Python und allen anderen bcrypt-Implementierungen. Alle Berechnungen erfolgen lokal im Browser.
Inhaltsverzeichnis
Schnellübersicht
- Bcrypt-Rechner: Passwörter mit bcryptjs hashen und verifizieren
- Hash inspizieren: Aufbau eines bcrypt-Hashes verstehen
- Cost-Analyse: Rechenzeit je Kostenfaktor visualisiert
- Theorie: Über bcrypt, Salt und Cost-Faktor
- Geschichte: Von Unix crypt zu bcrypt und Argon2
- FAQ: Häufige Fragen zu bcrypt
- Zusammenfassung: Die wichtigsten Punkte
- Weitere Tools: Verwandte Sicherheits-Tools
1. Bcrypt Tool
Gib ein echtes Passwort ein – der bcrypt-Hash wird mit der offiziellen bcryptjs-Bibliothek berechnet.
Der Kostenfaktor (Cost) bestimmt die Rechenzeit. Höherer Cost = sicherer, aber langsamer.
| Bestandteil | Länge | Beispiel | Bedeutung |
|---|---|---|---|
| Prefix | 3 Zeichen | $2a$ | bcrypt-Variante |
| Cost | 2 Zeichen | 12 | 2^12 = 4.096 Runden |
| Salt | 22 Zeichen | N9qo8uLOickgx2ZMRZoMye | 16 Byte, Base64-kodiert |
| Hash | 31 Zeichen | IjZAgcfl7p92ldGxad68LJZdL17lhWy | 23 Byte, Base64-kodiert |
| Gesamt | 60 Zeichen | Standard-Bcrypt-Hash-Länge | |
2. Theorie – Bcrypt und Passwort-Hashing
Verstehe, warum bcrypt für Passwörter besser ist als SHA-256.
Was ist bcrypt?
bcrypt ist eine adaptive Hash-Funktion für Passwörter, basierend auf dem Blowfish-Algorithmus:
- Entwickelt 1999: Niels Provos und David Mazières
- Adaptiv: Kostenfaktor einstellbar
- Salt integriert: Automatisch generiert
- Langsam: Absichtlich rechenintensiv
- Standard: Für Passwörter empfohlen
Warum bcrypt statt SHA-256?
SHA-256 ist zu schnell für Passwörter:
- GPU: Milliarden SHA-256/s möglich
- ASIC: Billionen/s bei Bitcoin-Minern
- Brute-Force: 8-Zeichen-Passwort in Stunden
- bcrypt: Nur tausende/s pro GPU
- Faktor: ~10.000× langsamer als SHA-256
Kostenfaktor (Cost)
Der Cost-Faktor steuert die Rechenzeit:
- Formel: 2^Cost Runden
- Cost 10: 1.024 Runden
- Cost 12: 4.096 Runden
- Cost 14: 16.384 Runden
- Verdopplung: Cost +1 = 2× langsamer
Empfehlung 2025: Cost 12 für die meisten Anwendungen.
Best Practices
- Cost: Mindestens 10, besser 12
- Cost testen: Ziel: 100-300 ms pro Hash
- Salt: Nie selbst generieren – bcrypt macht das
- Passwort-Länge: bcrypt limitiert auf 72 Bytes
- Pepper: Optional zusätzlicher geheimer Schlüssel
- Argon2: Moderne Alternative zu bcrypt
- Bcrypt wurde 1999 von Niels Provos und David Mazières entwickelt – und ist bis heute einer der sichersten Passwort-Hashes.
- Der Name kommt von "B" (Blowfish) und "crypt" (Kryptographie).
- Bcrypt limitiert Passwörter auf 72 Bytes (nicht Zeichen!). Längere werden abgeschnitten.
- Der Prefix (
$2a$,$2b$,$2y$) zeigt die bcrypt-Variante –$2a$ist die gängigste. - Für neue Projekte empfehlen Sicherheitsexperten Argon2id – bcrypt bleibt aber weiterhin sicher.
3. Geschichte des Passwort-Hashings
Von DES-crypt zu bcrypt und Argon2.
Unix crypt (DES)
Erste Passwort-Hashing-Funktion in Unix. Basierend auf DES mit 25 Runden. Begrenzt auf 8 Zeichen und 12-Bit-Salt – heute völlig unsicher.
Blowfish
Bruce Schneier veröffentlicht Blowfish – eine schnelle Blockchiffre. Wird zur Grundlage für bcrypt. Blowfish ist bis heute ungebrochen.
Bcrypt veröffentlicht
Niels Provos und David Mazières entwickeln bcrypt. Der Kostenfaktor macht den Hash adaptiv – kann an schnellere Hardware angepasst werden.
Standard in Web-Frameworks
bcrypt wird zum Standard in PHP, Ruby on Rails, Django, Node.js. Millionen von Anwendungen nutzen bcrypt für Passwort-Sicherheit.
Password Hashing Competition
Die PHC wählt Argon2 als Gewinner. Moderne Alternative zu bcrypt mit besserem Schutz gegen GPU/ASIC-Angriffe.
Migration zu Argon2
Viele Projekte migrieren von bcrypt zu Argon2id. bcrypt bleibt aber weiterhin sicher und wird milliardenfach genutzt.
bcrypt.js v3
bcryptjs v3 veröffentlicht – mit verbesserter Performance, TypeScript-Support und native Web-Crypto-Integration. Wird zum Standard für Browser-basiertes bcrypt.
Bcrypt & Argon2 parallel
bcrypt ist der Standard für bestehende Systeme, Argon2id für neue Projekte. Beide sind sicher gegen Brute-Force.
4. FAQ – Häufige Fragen
Häufige Fragen zu bcrypt
bcrypt ist eine speziell für Passwörter entwickelte Hash-Funktion:
- Adaptiv: Kostenfaktor einstellbar (2^Cost Runden)
- Salt integriert: Automatisch generiert und im Hash gespeichert
- Absichtlich langsam: ~512 ms pro Hash bei Cost 12
- Bewährt: Seit 1999 im Einsatz, nie gebrochen
Warum nicht SHA-256?
- SHA-256 ist zu schnell – GPUs schaffen Milliarden/s
- Ein 8-Zeichen-Passwort ist in Stunden gebrochen
- bcrypt ist 10.000× langsamer als SHA-256
- Brute-Force wird wirtschaftlich unmöglich
Faustregel: Ziel ist 100-300 ms pro Hash auf deinem Server.
| Cost | Zeit | Empfehlung |
|---|---|---|
| 4 | ~16 ms | Nur Tests/Entwicklung |
| 8 | ~64 ms | Schnelle Web-Anwendungen |
| 10 | ~128 ms | Minimum für Produktion |
| 12 | ~512 ms | Standard-Empfehlung 2025 |
| 14 | ~2 s | Maximale Sicherheit |
Wichtig:
- Testen: Auf Produktionshardware messen
- Anpassen: Alle 2-3 Jahre Cost erhöhen
- Login-Zeit: Nicht über 500 ms gehen
- DoS-Schutz: Rate Limiting beim Login!
| Merkmal | SHA-256 | bcrypt | Argon2id |
|---|---|---|---|
| Geschwindigkeit | Sehr schnell | Langsam (adaptiv) | Sehr langsam (adaptiv) |
| Salt | Manuell | Automatisch | Automatisch |
| Memory-Hard | Nein | Nein | Ja |
| GPU-resistent | Nein | Teilweise | Ja |
| Standard | Integrität | Passwörter | Neue Projekte |
| Empfehlung | ❌ Nicht für Passwörter | ✅ Ja | ✅ Beste Wahl |
Wann was?
- SHA-256: Datei-Integrität, Signaturen, Checksums
- bcrypt: Passwörter in bestehenden Systemen
- Argon2id: Neue Projekte, höchste Sicherheit
Bcrypt verarbeitet nur die ersten 72 Bytes eines Passworts:
- Byte ≠ Zeichen: Umlaute können 2 Bytes belegen
- Bei 72 Bytes: Alles danach wird ignoriert
- Konsequenz: Zwei Passwörter mit gleichem Anfang sind identisch
Beispiel:
MeinLangesPasswort...+72BytesMeinLangesPasswort...+72Bytes+EXTRA- Sind für bcrypt identisch!
Lösungen:
- Passwort vorher hashen: SHA-256 → Base64 → bcrypt
- Argon2 nutzen: Keine Längenbegrenzung
- Passwort-Validierung: Maximum 72 Bytes
Unser Tool warnt automatisch via bcrypt.truncates()!
Der Prefix zeigt die bcrypt-Variante:
| Prefix | Bedeutung |
|---|---|
$2$ | Original (1999) – Bug bei Länge 0 |
$2a$ | Aktuelle Variante – Standard |
$2b$ | Alternative (OpenBSD) – selten genutzt |
$2x$ | PHP (fehlerhaft) – nicht mehr verwenden |
$2y$ | PHP (korrigiert) – Nachfolger von $2x$ |
In der Praxis:
- $2a$: Standard in den meisten Sprachen
- $2b$: OpenBSD-Standard
- $2y$: PHP (seit Version 5.5.0)
Kompatibilität: Alle Varianten sind untereinander kompatibel (außer $2x$).
Ja, bcrypt ist 2025 immer noch sicher – aber es gibt neue Alternativen:
Pro bcrypt:
- Bewährt: Seit 1999 im Einsatz
- Nie gebrochen: Keine erfolgreichen Angriffe
- Adaptiv: Cost anpassbar
- Standard: In Millionen Anwendungen
Contra bcrypt:
- 72-Byte-Limit: Unbequem für lange Passwörter
- Nicht memory-hard: GPUs können parallelisieren
- Argon2 besser: Memory-Hard-Algorithmus
- Nicht mehr "modern": Seit 26 Jahren im Einsatz
Empfehlung:
- Bestand: Bei bcrypt bleiben
- Neue Projekte: Argon2id evaluieren
- Migration: Nicht zwingend nötig
Test-Szenarien:
- 1. Geschwindigkeit: 100 Hashes generieren, Zeit messen
- 2. Ziel: 100-500 ms pro Hash (Cost 10-12)
- 3. Verifizieren: Richtiges Passwort → Match
- 4. Verifizieren: Falsches Passwort → Kein Match
- 5. Salt: Zwei gleiche Passwörter → verschiedene Hashes
- 6. Cost-Änderung: Bestehende Hashes müssen weiter funktionieren
Beispiel-Test mit diesem Tool:
- Passwort eingeben, Cost 12 wählen
- Hash generieren, Zeit messen
- Zweiten Hash generieren → anderer Hash! (Salt)
- Zum Verifizieren-Modus wechseln
- Passwort + Hash eingeben → Match
Nein, das ist NICHT empfohlen!
Warum nicht:
- Hash wird zum Passwort: Der clientseitige Hash ist das neue Passwort
- Replay-Angriff: Angreifer kann den Hash abfangen und wiederverwenden
- Kein Vorteil: HTTPS schützt bereits die Übertragung
- Salt-Problem: Client kennt den Server-Salt nicht
Richtige Architektur:
- 1. HTTPS: Verschlüsselte Übertragung
- 2. Server: Passwort mit bcrypt/Argon2 hashen
- 3. Datenbank: Nur den Hash speichern
- 4. Login: Passwort senden, Server verifiziert
Ausnahme: "Zero-Knowledge"-Systeme (z.B. Bitwarden) nutzen clientseitiges Hashing – aber mit spezieller Architektur.
Zusammenfassung
Die wichtigsten Punkte
- Bcrypt: Adaptive Hash-Funktion für Passwörter (seit 1999)
- Cost-Faktor: 2^Cost Runden, empfohlen 12 für 2025
- Salt: Automatisch generiert und im Hash gespeichert
- Format:
$2a$12$Salt...Hash(60 Zeichen) - 72-Byte-Limit: Passwörter werden begrenzt
- Empfehlung: bcrypt Cost 12 oder Argon2id
- Nicht clientseitig: Immer auf dem Server hashen
- Rate Limiting: Schutz vor DoS-Angriffen
- bcryptjs v3: Echte Bibliothek für Browser & Node.js
- Unser Tool: Hash + Verify + Inspect in einem
Weitere Sicherheits-Tools
Passwort-Stärke mit Entropie und Knackzeiten prüfen.
Zum ToolMD5, SHA-1, SHA-256 und SHA-512 für Text und Dateien.
Zum ToolRSA, ECC, AES und DH Schlüsselstärken nach NIST vergleichen.
Zum ToolDatei-Integrität mit MD5, SHA-1, SHA-256 und SHA-512 prüfen.
Zum Tool