Bcrypt gibt es, weil Schnelligkeit bei einem Passwort-Hash ein Mangel ist. Ein Allzweck-Hash wie SHA-256 ist darauf ausgelegt, so schnell wie möglich zu laufen — genau das, was jemand braucht, der Milliarden Versuche durchprobiert. Bcrypt ist absichtlich langsam, und der Kostenfaktor bestimmt wie langsam: Jede Stufe verdoppelt den Aufwand, ein Kostenwert von 12 dauert also viermal so lange wie 10 — für Sie einmal beim Anmelden, für einen Angreifer bei jedem einzelnen Versuch.
Ein Salt wird für Sie erzeugt und im Ergebnis eingebettet, weshalb dasselbe Passwort zweimal gehasht zwei verschiedene Zeichenketten ergibt und keines von beiden separat gespeichert werden muss. Der fertige Wert trägt seinen Algorithmus, seinen Kostenwert und sein Salt in sich, für die spätere Prüfung braucht es also nichts außer dem Hash selbst. Die Prüfseite vergleicht ein Passwort mit einem vorhandenen Hash über einen zeitkonstanten Vergleich statt über simple Zeichenkettengleichheit.
Einen Kostenwert wählen und die Ausgabe lesen
-
Zehn ist die übliche Untergrenze, zwölf ein vernünftiges Ziel:
Die richtige Zahl ist die höchste, die Ihr Server bei Ihrer Anmelderate verkraftet. Hier stehen Werte von vier, das nur zum Testen taugt, bis vierzehn zur Verfügung.
-
Nur die ersten 72 Bytes werden gelesen:
Bcrypt schneidet darüber hinaus stillschweigend ab, eine sehr lange Passphrase ist also nicht so stark, wie ihre Länge vermuten lässt. Längere Eingaben werden hier abgelehnt statt klammheimlich gekürzt.
-
Zwei Hashes desselben Passworts unterscheiden sich:
Das ist das Salt bei der Arbeit. Vergleichen Sie niemals Hashes miteinander — vergleichen Sie ein Passwort mit einem Hash, was die Prüfseite tut.
-
Im Browser zu hashen dient dem Testen, nicht dem Produktivbetrieb:
Eine echte Anmeldung hasht auf dem Server. Hier einen Hash zu erzeugen, um ein Konto anzulegen oder einen gespeicherten Wert zu prüfen, ist in Ordnung; ein Passwort an eine Webseite zu schicken nicht.
Being fast is the defect bcrypt was built to fix
A general-purpose hash such as SHA-256 is built to run as fast as possible, which is precisely what someone testing billions of password guesses wants from it. The [msm_tool slug="bcrypt-generator"] is deliberately slow instead, and the cost factor sets exactly how slow: each step up doubles the work required, so cost 12 takes four times as long as cost 10 — once, for a real sign-in, and on every single attempt for anyone guessing.
Choosing a cost
Ten is the usual floor and twelve a reasonable target where the server can afford it; costs from four up to fourteen are offered here, with four useful only for testing rather than anything live. The right number is the highest one a sign-in rate can absorb without becoming a problem of its own, since the same slowness that defends against guessing also costs real time on every legitimate attempt.
Only the first 72 bytes are read
Bcrypt silently truncates anything past 72 bytes of input, which means an unusually long passphrase is not actually as strong as its length suggests. Input beyond that limit is refused outright here rather than quietly accepted and hashed as something weaker than it appears to be.
Two hashes of the same password will never match
A fresh salt is generated for every run and embedded directly in the result, which is why hashing an identical password twice produces two different strings and why nothing needs to be stored separately from the hash itself. Comparing two hashes to each other is consequently the wrong operation entirely — the only valid comparison is a password against a hash, which is what the verify side actually performs, using a constant-time comparison rather than plain string equality.
A browser is for testing and seeding, not for live sign-in
Generating a hash here to seed an account manually or check a value already sitting in a database is a reasonable use. Sending a real, live password to any page as part of an actual sign-in is a different matter entirely — that hashing belongs on the server, every time, regardless of how convenient a page like this one is.
Bcrypt against the newer alternatives
Bcrypt remains sound for most applications and is supported essentially everywhere. Argon2 is the newer recommendation and holds up better against attacks that use specialised hardware, but choosing bcrypt today is not a mistake — it is a well-understood, still-current choice rather than a legacy one being phased out.