Bcrypt-Hash-Generator & -Prüfer
Verwandle ein Passwort in einen $2b$-bcrypt-Hash oder prüfe ein Passwort gegen einen bereits vorhandenen Hash. Das Hashing läuft in einem Web Worker in deinem Browser – nichts, was du eingibst, wird irgendwohin gesendet.
Füge niemals ein echtes Produktiv-Passwort in ein Online-Tool ein – auch nicht in dieses.
Eingabe
Passwort und Kostenfaktor
Für jeden Hash wird ein frisches 16-Byte-Salt gezogen, sodass dasselbe Passwort jedes Mal einen anderen Hash ergibt. Das ist der Sinn eines Salts, kein Bug.
Kostenfaktor 10 bedeutet 2^10 = 1,024 Key-Setup-Runden. Jede Stufe verdoppelt den Aufwand – für jemanden, der eine gestohlene Passwortdatei durchprobiert, und für deinen eigenen Server bei jedem einzelnen Login. Die meisten Produktivsysteme liegen zwischen 10 und 12.
Die drei Präfixe erzeugen für Passwörter unter 72 Byte identische Hash-Bytes; nur das Label unterscheidet sich. PHPs mitgeliefertes crypt() erkennt $2b$ nicht, weshalb ein $2b$-Hash bei password_verify() stillschweigend fehlschlägt. Wähle $2y$ für PHP.
Das Hashing läuft in einem Web Worker in diesem Tab. Das Passwort wird nie an Wespner oder sonst jemanden gesendet – es gibt keinen Request, der es verschicken könnte.
Ergebnis
bcrypt-Hash
Klicke auf „Hash erzeugen“.
Kosten, hier gemessen
Was diese Einstellung dich kostet
Schätzung: Ein Hash wird in diesem Tab bei Kostenfaktor 8 gemessen, jeder andere Kostenfaktor wird durch Verdopplung davon hochgerechnet. Deine eigene Hardware und dein Browser bestimmen die Zahl.
Diese Zahlen stammen von einem einzelnen JavaScript-Thread. Ein echter Angreifer lässt nativen Code auf einem Rack voller GPUs laufen und ist um Größenordnungen schneller – genau deshalb muss der Kostenfaktor unbequem statt bequem sein. Derselbe Regler bestimmt auch, wie viel CPU jeder einzelne Login bei dir verbrennt.
Den String lesen
Was die 60 Zeichen bedeuten
$2b$12$LQv3c1yqBWVHxkd0LHAkCOYUtYgBuLIjrsGrDUgYqZbY7d0RfPbtq
Beide Blöcke nutzen bcrypts eigenes Base64-Alphabet, das mit ./ beginnt und die Ziffern ans Ende stellt – das ist kein Standard-Base64, und es wie eines zu dekodieren liefert falsche Bytes. Das, zusammen mit dem 22/31-Split, ist eine schnelle Möglichkeit zu prüfen, ob ein String wirklich ein bcrypt-Hash ist und nicht nur so aussieht.
Einen Algorithmus wählen
bcrypt, scrypt oder Argon2?
Dieses Tool ist absichtlich nur für bcrypt. Hier siehst du, wann das die richtige Wahl ist und wann nicht.
Absichtlich langsam, stützt sich aber nur auf CPU-Zeit und feste 4 KB Speicher. GPUs und FPGAs parallelisieren das deutlich besser als die neueren Designs. Trotzdem eine völlig respektable Wahl, wird buchstäblich überall unterstützt, und das 72-Byte-Passwortlimit ist ihre überraschendste Falle.
Fügt einstellbare Speicherkosten hinzu, sodass ein Angreifer RAM pro Versuch braucht, nicht nur Kerne. Schwerer günstig zu parallelisieren als bcrypt.
Gewinner der Password Hashing Competition 2015 und das, was OWASP heute für neue Systeme empfiehlt: separate Regler für Zeit, Speicher und Parallelität, wobei die id-Variante sowohl GPU- als auch Seitenkanalangriffen widersteht. Wenn du neu startest und deine Plattform es unterstützt, nutze es. Pflegst du ein System, das bereits $2y$-Hashes speichert, ist bcrypt mit sinnvollem Kostenfaktor kein Notfall — rehashe stattdessen beim nächsten Login.
Nachweis
Diese Seite gegen die veröffentlichten Testvektoren prüfen
Ein Hashing-Tool, dem man vertrauen soll, sollte überprüfbar sein. Das sind die von OpenBSD-Implementierungen verwendeten Referenz-bcrypt-Vektoren; die Seite berechnet jeden davon aus seinem eigenen Salt neu und vergleicht Zeichen für Zeichen, dann hasht und verifiziert sie ein Wegwerf-Passwort bei zwei Kostenfaktoren.
Der Durchlauf prüft 6 veröffentlichte Vektoren plus zwei Round Trips.
Betreibst du einen eigenen Gameserver?
Wespner-Gameserver mit DDoS-Schutz, NVMe-Laufwerken und Aktivierung innerhalb von Minuten.