Zum Inhalt springen

bcrypt- und argon2-Prüfer

bcrypt & argon2 Checker

Hasht ein Passwort mit bcrypt bei gewähltem Kostenfaktor und prüft ein Passwort gegen einen vorhandenen bcrypt-Hash. Erkennt argon2, berechnet es aber nicht.

Hasht ein Passwort mit bcrypt oder prüft ein Passwort gegen einen vorhandenen `$2a$`/`$2b$`/`$2y$`-Hash. Die Implementierung ist OpenBSDs `$2b$`, verifiziert gegen die veröffentlichten Openwall-crypt_blowfish-Testvektoren, und sie läuft in einem Worker in diesem Tab.

🔒 Läuft vollständig in Ihrem Browserbcryptargon2passwordhash
Modus

Wird nur in diesem Tab verarbeitet; nichts wird übertragen.

Kostenfaktor

1.024 Runden — der langjährige Standardwert.

Das ist bcrypt so, wie OpenBSD $2b$ definiert, gegen die veröffentlichten Openwall-crypt_blowfish-Testvektoren geprüft und vollständig in diesem Tab laufend. Nur die ersten 72 Byte eines Passworts zählen — so ist bcrypt, das ist kein Fehler hier. $2x$-Hashes (entstanden durch einen crypt_blowfish-Fehler von vor 2011) werden abgelehnt, und argon2 ist nicht implementiert.

So funktioniert es

  1. Wählen Sie Hashen oder Prüfen

    Hashen braucht einen Kostenfaktor; Prüfen liest den Kostenfaktor aus dem Hash, den Sie einfügen, denn er ist im String gespeichert.

  2. Wählen Sie einen Kostenfaktor, den Sie sich leisten können

    Jede Stufe verdoppelt die Arbeit. 10 war jahrelang der Standard, 12 ist eine solide aktuelle Wahl, und 14 braucht in einem Browser ein paar spürbare Sekunden – was der Punkt ist: Ein Angreifer braucht genauso lange.

  3. Lesen Sie das Urteil

    Übereinstimmung oder keine Übereinstimmung. Alles geschieht im Tab, sodass ein hier eingefügter Produktions-Hash nirgendwohin reist.

Häufige Fragen

Warum wird argon2 verweigert statt unterstützt?

Weil ein vertrauenswürdiges argon2 im Browser hieße, einen WebAssembly-Build auszuliefern, den dieses Projekt nicht Zeile für Zeile prüfen kann. bcrypt ist hier in Code implementiert, den Sie lesen können, geprüft gegen veröffentlichte Vektoren. Einen argon2-Hash zu verweigern ist ehrlicher als eine plausibel aussehende Antwort aus einer Blackbox.

Warum verifiziert mein langes Passwort gegen den falschen Hash?

bcrypt liest nur die ersten 72 Bytes. Zwei Passwörter, die sich ihre ersten 72 Bytes teilen, sind für es dasselbe Passwort – das ist bcrypt selbst, nicht diese Implementierung. Bei einer Passphrase zählt das, und es ist ein Grund, warum man zu argon2 wechselt.

Warum ergibt zweimaliges Hashen desselben Passworts verschiedene Strings?

Weil jeder Durchlauf ein frisches 16-Byte-Salt erzeugt, und das Salt reist im Hash mit. Beide Strings verifizieren dasselbe Passwort. Ein Passwort-Hash, der jedes Mal gleich ist, ist ein Passwort-Hash ohne Salt, und dafür wurden Rainbow-Tables gebaut.

Sind $2a$, $2b$ und $2y$ verschieden?

Nicht für ein Passwort von 72 Bytes oder weniger, und das sind alle. Die Präfixe halten fest, vor oder nach welchem historischen Bug ein Hash erzeugt wurde. `$2x$` ist die Ausnahme – es markiert Hashes aus einem crypt_blowfish-Bug von vor 2011, und die werden hier verweigert.

Eingabe aus

Danach

Diese Tools nehmen an, was dieses hier erzeugt, das Ergebnis kann also direkt weiter.