bcrypt-Generator

bcrypt ist nach wie vor eine der sichersten Optionen zur Speicherung von Passwörtern. Es ist absichtlich langsam, leitet sein eigenes Salt ab und skaliert mit Hardwareverbesserungen durch einen anpassbaren Kostenparameter. Dieser Generator erzeugt einen standardskonformen bcrypt-Hash aus einem Klartextpasswort, sodass Sie einen Testbenutzer anlegen, ein Konto zwischen Systemen migrieren oder Werte mit einem vorhandenen Hash in einer users.password-Spalte vergleichen können.

So hashen Sie ein Passwort mit bcrypt

  1. 1

    Geben Sie das Klartextpasswort ein

    Bis zu 72 Bytes — bcrypt schneidet darüber hinaus stillschweigend ab.

  2. 2

    Wählen Sie einen Kostenfaktor

    10 ist der aktuelle Standard; 12 ist für neue Systeme üblich; 14 ist paranoid. Jeder +1 verdoppelt ungefähr die Hash-Zeit.

  3. 3

    Ein zufälliges Salt wird generiert

    16 Bytes Salt werden aus einem kryptografischen RNG entnommen und in den resultierenden Hash-String eingebettet.

  4. 4

    Kopieren Sie den Hash

    Die Ausgabe ist ein selbstbeschreibender String wie `$2b$12$...`, der Version, Kosten, Salt und Digest enthält.

Anatomie eines bcrypt-Hashes

$2b$12$mE2n5YqWjKqT9tXg.OQPoeeHZJ9hdSvOt5wFdRRQwl6yE1vWWY3z6
  |   |  |                      |
  |   |  Salt (22 Base64-Zeichen)  Digest (31 Base64-Zeichen)
  |   Kosten (2 Ziffern, 4-31)
  Version (2a, 2b, 2y — alle bcrypt)

Der gesamte String hat 60 Zeichen. Spalten vom Typ VARCHAR(60) oder CHAR(60) sind das Standard-Schema.

Empfehlungen für Kostenfaktoren

Kosten Ungefähr Zeit pro Hash (2024 CPU) Anwendungsfall
10 ~80 ms Legacy-Standard, immer noch akzeptabel
12 ~300 ms Aktuell empfohlene Basislinie
13 ~600 ms Höhere Sicherheitsanwendungen
14 ~1,2 s Paranoid; spürbare Anmeldeverzögerung

Jede Erhöhung verdoppelt den Arbeitsfaktor. Wenn die Anmeldeverzögerung unter 500 ms kritisch ist, bleiben Sie bei 10-12.

Versionsbyte: 2a vs 2b vs 2y

  • $2a$ — Original-Spezifikation von 1999. Die meisten Bibliotheken erzeugen 2a-Hashes.
  • $2b$ — Überarbeitung von 2014, die einen Truncationsfehler in crypt_blowfish behebt. Bevorzugt für neue Hashes.
  • $2y$ — PHP-spezifisches Tag, funktional äquivalent zu $2b$.

Alle drei verifizieren gegeneinander; nur das Tag im Hash-String unterscheidet sich.

Wogegen bcrypt schützt

  • Regenbogentabellen — Einzigartiges Salt pro Hash besiegt vorab berechnete Suchen.
  • GPU/ASIC-Cracking — Der Blowfish-Schlüsselplan ist speichergebunden und feindlich gegenüber GPUs. Nicht so GPU-feindlich wie Argon2, aber immer noch langsam zu brute-forcen.
  • Datenbanklecks — Das Klartextpasswort ist aus dem Hash ohne Brute-Force nicht wiederherstellbar.

Wogegen bcrypt NICHT schützt: schwache Passwörter (verwenden Sie eine Mindestlänge und überprüfen Sie gegen Verletzungslisten), Credential Stuffing (verwenden Sie einen zweiten Faktor), Phishing.

72-Byte-Grenze

bcrypt verwendet nur die ersten 72 Bytes des Passworts. Längere Eingaben werden stillschweigend abgeschnitten, was der Grund ist, warum viele Bibliotheken jetzt empfehlen, das Passwort vor der Übergabe an bcrypt mit SHA-256 vorzuhaschen. Moderne Alternativen (Argon2, scrypt) haben keine solche Grenze.

Häufig gestellte Fragen

Ja für die Passwortspeicherung, bei Kosten ≥ 12. OWASP listet es weiterhin als akzeptable Algorithmus. Argon2id ist die bevorzugte Wahl für neue Systeme, aber die Migration von Legacy-bcrypt-Hashes ist ein Anliegen mit niedriger Priorität.

Weil das Salt pro Hash zufällig generiert wird. Die Verifizierung nimmt das Salt aus dem gespeicherten Hash, hasht das übermittelte Passwort damit erneut und vergleicht.

Die meisten Bibliotheken bieten dies nicht an, und aus gutem Grund — vorhersehbare Salts untergraben den Zweck. Verwenden Sie das von der Bibliothek generierte Salt; das ist der sichere Weg.

Ja — der Arbeitsfaktor ist symmetrisch. Die Verifizierung eines Kosten-14-Hashes dauert 16x länger als die Verifizierung eines Kosten-10-Hashes. Passen Sie es mit Ihrem Anmelde-Durchsatz im Hinterkopf an.

Verwandte Tools