Bcrypt Generator – Passwort-Hashes online erstellen

Für die meisten Produktionssysteme ist ein Work Factor von 12 ein solider Standardwert, der auf typischer Serverhardware etwa 250 bis 400 Millisekunden pro Hash liefert, während Kosten von 10 inzwischen oft zu schnell sind, um einem Angreifer mit modernen GPUs standzuhalten. Entscheidend ist, dass Sie einen Wert wählen, der Ihren eigenen Anmeldefluss unauffällig erscheinen lässt, denn das Hashing findet während der Authentifizierung statt und alles spürbar Langsame ist ein Bedienungsproblem, das Menschen zu Abkürzungen bei der erneuten Authentifizierung drängt. Wenn Ihre Server ungewöhnlich leistungsfähig sind, messen Sie bei Kosten 12 und steigen Sie auf 13 oder 14, bis ein einzelner Hash ein paar Hundert Millisekunden braucht. Wählen Sie Kosten niemals, indem Sie die Zahl eines anderen Projekts übernehmen, denn dieser Wert bedeutet nur im Verhältnis zur rechnenden Hardware etwas, und behandeln Sie jede gespeicherte Kostenangabe als Wert, den Sie mit besserer Hardware erneut messen und erhöhen sollten.

Weil bcrypt für jeden einzelnen Hash ein frisches zufälliges 128-Bit-Salz erzeugt. Dieses Salz ist kein Geheimnis, es wird lediglich in der Ausgabe festgehalten, damit der Prüfschritt die ursprüngliche Rechnung reproduzieren kann; seine Zufälligkeit sorgt aber dafür, dass identische Passwörter über verschiedene Konten hinweg völlig unzusammenhängende Hash-Zeichenketten ergeben. Das vereitelt eine große Klasse von Vorabberechnungsangriffen einschließlich Rainbow Tables, bei denen ein Angreifer jedes wahrscheinliche Passwort einmal im Voraus hasht und dann Treffer nachschlägt. Es verhindert auch ein subtileres Leck, bei dem ein Angreifer im Besitz Ihrer Benutzertabelle sonst sofort durch Vergleich der Hash-Zeichenketten sähe, welche Konten ein Passwort teilen. Praktisch heißt das, dass Sie eine Wiederverwendung von Passwörtern nicht durch Vergleich gespeicherter bcrypt-Hashes erkennen können, sondern Kandidatenpasswörter prüfen müssen, weshalb das Erkennen von Passwortwiederverwendung ein bewusstes Durchprobieren erfordert.

Verwenden Sie bcrypt, und der Grund ist der Kostenfaktor, nicht irgendeine kluge Mathematik. Eine einzelne Runde SHA-256 ist darauf ausgelegt, extrem schnell zu sein, und genau das wollen Sie für die Passwortspeicherung nicht, denn eine GPU kann Milliarden davon pro Sekunde berechnen, und ein Angreifer, der eine geleakte Hash-Tabelle testet, bekommt enorm viele kostenlose Versuche. bcrypt ist absichtlich langsam und seine Kosten pro Hash sind einstellbar, sodass Sie sie im Laufe der Zeit mit besserer Hardware erhöhen können, ohne das gespeicherte Format zu ändern. Argon2id wird heute, wo verfügbar, oft bevorzugt und ist für neue Systeme generell die stärkere Empfehlung, wobei bcrypt nach wie vor völlig in Ordnung und weit verbreiteter unterstützt ist. Was Sie auf keinen Fall tun dürfen, ist Passwörter als einfaches SHA-256 oder als ungesalzenen Hash irgendeiner Art zu speichern, egal welchen Algorithmus Sie wählen.

Nein, und genau das ist der gesamte Sinn der Wahl eines Passwort-Hashes gegenüber Verschlüsselung. bcrypt ist eine Einwegfunktion, es gibt also keinen Schlüssel, keine Einstellung und kein kostenpflichtiges Werkzeug, das einen Hash zurück in das Passwort verwandelt. Der einzige praktische Weg, ein Passwort aus einem bcrypt-Hash zu gewinnen, besteht darin, Passwortkandidaten zu erraten, jeden mit denselben Kosten und demselben Salt zu hasht und zu vergleichen, und genau diesen Angriff soll bcrypt langsam machen. Das erklärt auch eine Einschränkung, die Menschen überrascht: Sie können bcrypt nicht für Daten verwenden, die Sie später wieder auslesen müssen, etwa gespeicherte Kartennummern, Kundenschlüssel zur Verschlüsselung oder eine umkehrbare Passwortwiederherstellung, weil das System den Originalwert nicht zurückerhalten könnte. Dafür braucht es echte Verschlüsselung mit einem verwalteten Schlüssel, keinen Einweg-Hash.

Dann kann der Hash nie verifiziert werden und das Konto ist unwiederbringlich, denn bcrypt benötigt alle vier Teile der Zeichenkette, um die Rechnung zu reproduzieren. Ein vollständiger bcrypt-Hash besteht aus Versionspräfix, Kosten, Salt und resultierendem Hash, verbunden durch Dollarzeichen, und ist immer 60 Zeichen lang. Bibliotheken wie bcryptjs und das Python-Paket bcrypt liefern diese gesamte Zeichenkette aus einem einzigen generate-Aufruf, deshalb sollte Ihre Datenbankspalte den vollständigen Wert speichern und nicht einen abgeschnittenen Teil. Speichert man nur das letzte Segment oder nur den Teil nach dem Salt, bricht die Anmeldung für jeden Benutzer stillschweigend, und keine noch so gründliche Fehlersuche am Passwort hilft. Eine Längenprüfung von 60 Zeichen ist ein sinnvoller Plausibilitätstest für jede Spalte, die bcrypt-Hashes aufnehmen soll.

bcrypt berücksichtigt nur die ersten 72 Bytes des Passworts und ignoriert alles darüber hinaus, ein historisches Artefakt seines Blowfish-Schlüsselschemas und keine bewusste Sicherheitsgrenze. Praktisch bedeutet das, dass zwei Passwörter mit mehr als 72 Bytes, die ein gemeinsames Präfix haben, gegeneinander authentifizieren, eine 100 Zeichen lange Passphrase, deren erste 72 Bytes mit einer anderen übereinstimmen, wird also ebenfalls als dasselbe Passwort behandelt. Das ist ein reales Risiko bei langen Passphrasen, also genau bei der Art von Passwort, die Sie fördern sollten, und lange Werte wie vollständige Sätze können die Grenze problemlos überschreiten. Die übliche Abhilfe ist, das Passwort vorher mit SHA-256 zu hasht und base64 zu kodieren und dieses feste Längen-Ergebnis an bcrypt zu übergeben. Wenn Ihre Sprachbibliothek das automatisch erledigt, verwenden Sie bevorzugt diese Implementierung, andernfalls prüfen Sie das Verhalten, bevor Sie sich auf sehr lange Passphrasen verlassen.