Alle Artikel

Bcrypt: warum Passwörter langsam gehasht werden, nicht schnell

Das BSI erlaubt bcrypt in der technischen Richtlinie TR-02102-1 weiterhin als akzeptable Alternative zur Passwortspeicherung, sofern der Cost-Faktor mindestens 12 beträgt und Argon2id nicht verfügbar ist — ein pragmatischer Kompromiss für Legacy-Systeme, die nicht ohne Weiteres migriert werden können. Das macht bcrypt in deutschen Unternehmen mit gewachsenen Codebasen (etwa alten Java- oder .NET-Anwendungen) oft zur praktischen Wahl, auch wenn Argon2id für Neuentwicklungen empfohlen wird.

Warum Geschwindigkeit der Passwortsicherheit schadet

Wenn ein Angreifer eine Datenbank mit Passwort-Hashes stiehlt, versucht er, das ursprüngliche Passwort per Brute-Force zu erraten. Mit einer schnellen Funktion wie SHA-256 kann moderne Hardware Milliarden Kombinationen pro Sekunde prüfen. Dauert das Hashing eines einzelnen Passworts absichtlich etwa 100 Millisekunden, wird Brute-Force um Größenordnungen langsamer und teurer.

Was der Cost-Faktor ist

Der "Cost"-Parameter von bcrypt legt die Anzahl interner Runden als Zweierpotenz fest (2^cost, typischerweise 10 bis 12 — das BSI verlangt mindestens 12). Jede Erhöhung um eins verdoppelt in etwa die Rechenzeit pro Hash — und verdoppelt ebenso die Gesamtkosten eines Brute-Force-Angriffs.

Eingebautes Salt

Bcrypt erzeugt automatisch ein einzigartiges zufälliges Salt für jedes Passwort und bettet es direkt ins Ergebnis ein — nichts muss separat gespeichert werden. Zwei identische Passwörter ergeben unterschiedliche Hashes, und vorberechnete Tabellen (Rainbow Tables) für gängige Passwörter werden nutzlos: jeder Hash muss einzeln angegriffen werden.

Wofür man das braucht

  • Benutzerpasswörter korrekt in der Datenbank einer Anwendung speichern.
  • Verstehen, warum SHA-256 oder MD5 eine schlechte Wahl für Passwort-Hashing sind.
  • Ein Authentifizierungssystem testen oder migrieren, das bcrypt verwendet — und dabei den Cost-Faktor gemäß BSI-Vorgabe auf mindestens 12 prüfen.

Die versteckte Grenze: 72 Byte

Bcrypt verarbeitet nur die ersten 72 Byte eines Passworts — alles darüber hinaus wird ohne Warnung einfach verworfen. In der Praxis ist das bei deutschen Passwörtern selten ein Problem (72 ASCII-Zeichen sind schon extrem lang), aber bei der Validierung der maximalen Passwortlänge in einem Formular lohnt es sich, diese Grenze zu kennen, besonders bei langen Passphrasen mit Umlauten oder ß.

Tool ausprobieren