Hashes/Krypto
Bcrypt Hash + Verify
Passwörter mit bcrypt hashen (mit zufälligem Salt und einstellbaren Kosten) und ein Passwort gegen einen vorhandenen bcrypt-Hash prüfen.
Bcrypt ist ein absichtlich langsamer Passwort-Hashing-Algorithmus: Anders als MD5 oder SHA-256 verlangt er bewusst hohen Rechenaufwand, damit Brute-Force-Angriffe auf Passwörter unpraktikabel bleiben, selbst wenn eine Datenbank mit Hashes geleakt wird.
So verwendest du es
- Hashen: Gib ein Passwort ein und setze einen Cost-Faktor — eine höhere Zahl bedeutet langsameres, sichereres Hashing.
- Jeder Hash-Aufruf erzeugt ein frisches Zufallssalt, sodass dasselbe Passwort jedes Mal einen anderen Hash ergibt — das ist normal und erwartet.
- Prüfen: Füge ein Passwort und einen vorhandenen bcrypt-Hash ein, um zu prüfen, ob sie übereinstimmen, ohne selbst manuell zu hashen.
Typische Anwendungsfälle
- Manuell prüfen, ob ein Backend Passwörter vor dem Speichern korrekt hasht.
- Einen Test-bcrypt-Hash für Seed-Daten oder Fixtures in der Entwicklung erzeugen.
- Einen fehlgeschlagenen Login debuggen, indem ein eingegebenes Passwort mit dem gespeicherten Hash verglichen wird.
Was du wissen solltest
Wähle einen Cost-Faktor, bei dem das Hashing auf dem Zielserver etwa 100–300 ms dauert — eine Balance zwischen Sicherheit und Login-Last.
Bcrypt kürzt Passwörter über 72 Byte ab — Zeichen darüber hinaus werden vom Algorithmus ignoriert.
Artikel zu diesem Tool: Bcrypt: warum Passwörter langsam gehasht werden, nicht schnell
Häufig gestellte Fragen
Warum enthält bcrypt einen "Cost"- oder "Rounds"-Faktor?
Der Kostenfaktor steuert, wie oft das Hashing intern wiederholt wird, sodass das Hashing mit steigendem Wert exponentiell langsamer wird. So lässt es sich bewusst langsam genug halten, um Brute-Force-Angriffen standzuhalten, selbst wenn Hardware schneller wird.
Warum hat der bcrypt-Hash immer dieselbe Länge, unabhängig von meinem Passwort?
Bcrypt erzeugt einen Hash fester Länge (typischerweise 60 Zeichen), der Algorithmusversion, Kostenfaktor, Salt und Hash zusammen kodiert — die Länge hängt nicht davon ab, wie lang oder kurz das ursprüngliche Passwort war.
Braucht bcrypt ein separates Salt-Feld?
Nein. Das Salt wird automatisch erzeugt und direkt in die Ausgabezeichenfolge eingebettet, sodass Sie es nicht separat speichern oder verwalten müssen — es ist immer enthalten, wenn Sie ein Passwort gegen den Hash prüfen.
Gibt es eine Begrenzung für die Passwortlänge bei bcrypt?
Ja, bcrypt verarbeitet nur die ersten 72 Byte eines Passworts — alles darüber hinaus wird ohne Warnung einfach verworfen. In der Praxis ist das selten ein Problem, aber man sollte es bei sehr langen Passwörtern oder Nicht-ASCII-Zeichen bedenken, bei denen ein Zeichen mehrere Byte belegen kann.
Warum wird bcrypt trotz Argon2 noch immer empfohlen?
Bcrypt ist seit Jahrzehnten in der Praxis erprobt, wird in allen Sprachen und Frameworks breit unterstützt und bleibt eine durchaus zuverlässige Wahl. Argon2 wird für neue Systeme wegen des Schutzes vor Angriffen auf GPU/ASIC bevorzugt empfohlen, aber bcrypt gilt nicht als unsicher — nur als weniger widerstandsfähig gegen spezialisierte Hardware.