Hash & Crypto Helpers
Ein Testpasswort eingeben und einen Datensatz erzeugen oder einen vorhandenen Hash prüfen.
Nur Testdaten verwenden. Passwörter bleiben im Seiten- und Worker-Speicher; keine Übertragung oder Ablage im Browserspeicher.
Teststandard: Kostenfaktor 10; erlaubt 4–14. Aufwand wächst mit 2^cost. Keine Sicherheitsempfehlung für den Produktivbetrieb.
Zufällig: jedes Mal 16 Bytes. Fest: bcrypt 16 Bytes, sonst 8–64. Hex ohne Leerzeichen oder 0x.
bcrypt und Argon2id verwenden kodierte Zeichenfolgen. scrypt/PBKDF2 nutzen HeyUtils-JSON, kein allgemeines Frameworkformat.
Testpasswort eingeben und den gewählten Vorgang starten.
Beim Wechsel einer Bibliothek kann ein Testlogin scheitern, obwohl das Passwort richtig erscheint. Mit dem Ablauf „Passwort hashen“ lassen sich dieselben Passwortbytes, derselbe Salt und derselbe Aufwand gezielt nachstellen. So wird aus einer Vermutung ein vergleichbarer Testfall.
Die Prüfung liest Algorithmus, Salt und Parameter aus dem gespeicherten Datensatz. Einstellungen im Erzeugungsmodus überschreiben diese Angaben nicht. Beginnen Sie mit dem bekannten Beispiel und ändern Sie dann jeweils nur eine Bedingung.
Beim Vorgang „Passwort hashen“ erzeugt der Zufallsmodus bei jedem Lauf einen neuen Salt aus 16 Bytes. Dadurch entstehen auch für dasselbe Passwort unterschiedliche Datensätze. Ein fester hexadezimaler Salt macht einen Test für den Vergleich mit einer anderen Implementierung wiederholbar.
Ein nicht passendes Passwort ist ein abgeschlossenes Prüfergebnis. Ein ungültiger Datensatz oder ein zu hoher Kostenwert wird dagegen vor der Berechnung abgewiesen. Diese Trennung hilft, den Inhalt des Passworts von Problemen mit dem gespeicherten Format zu unterscheiden.
Das Beispiel öffnet zunächst eine Ersetzungsvorschau. Nach dem Anwenden enthält der Prüfmodus ein erfundenes Passwort mit passendem bcrypt-Hash. Ändern Sie ein Zeichen und prüfen Sie erneut, um auch den negativen Fall zu sehen.
Im Erzeugungsmodus können Sie einen neuen Zufalls-Salt oder einen festen Salt wählen. Das feste Feld erwartet Hex-Bytes ohne Präfix, kein gewöhnliches Wort. bcrypt benötigt genau 16 Bytes, die übrigen Verfahren erlauben 8–64.
Strg/Cmd + Enter startet den ausgewählten Modus. Jede Eingabeänderung bricht laufende Arbeit ab und sperrt den Export des alten Ergebnisses. Kopieren und Herunterladen sind nach erfolgreicher Erzeugung oder passender Prüfung verfügbar.
Der Bcrypt-Generator arbeitet mit bcrypt, alternativ stehen scrypt, Argon2id und PBKDF2-HMAC-SHA-256 bereit. Pro Lauf wird genau ein Verfahren ausgeführt. Das dient einzelnen Testfällen und ist kein gleichzeitiger Vergleich der Geschwindigkeit oder Sicherheitsstärke.
bcrypt speichert Kostenfaktor und Salt im Hash. Argon2id verwendet PHC mit Version 19. Für scrypt und PBKDF2 enthält ein versionierter HeyUtils-JSON-Datensatz die Parameter sowie saltHex und hashHex. Damit bleiben die Angaben erhalten, die zum Prüfen benötigt werden.
Vor dem Rechnen werden auch Parameter aus eingefügten Hashes geprüft. Angezeigte Millisekunden beschreiben einen Lauf auf diesem Gerät; beim ersten Start kann das Laden der Bibliothek enthalten sein. Daraus lässt sich weder die Kapazität eines Servers noch dessen geeignete Konfiguration ableiten.
Der Kostenfaktor steuert den Rechenaufwand von bcrypt: Dieser wächst mit 2^cost. Ein höherer Wert erhöht auch die benötigte Zeit. Hier sind 4–14 erlaubt und 10 ist der Teststandard. Für ein Produktivsystem müssen Bibliothek, Hardware, gleichzeitige Anmeldungen und akzeptable Verzögerung gemeinsam gemessen werden.
Im Zufallsmodus wird für jeden Lauf ein neuer Salt erzeugt. Er beeinflusst das Ergebnis und ist im Datensatz gespeichert. Deshalb können verschiedene Hashes dasselbe Passwort bestätigen. Für einen deterministischen Vergleich müssen Passwortbytes, fester Salt, Verfahren und Parameter übereinstimmen.
Ja, unterstützt werden vollständige $2a$-, $2b$- und $2y$-Datensätze mit Kostenfaktor 4–14 und gültiger Kodierung. Ein vorgeschalteter Hash, ein zusätzlicher Pepper oder eine Normalisierung in der ursprünglichen Anwendung wird dabei nicht automatisch nachgestellt. Solche Verarbeitungsschritte müssen in dieser Anwendung geprüft werden.
Möglicherweise ist der Hash abgeschnitten, die Kodierung nicht kanonisch oder der Kostenfaktor zu hoch. scrypt und PBKDF2 müssen als HeyUtils-JSON vorliegen. Ein Fehler beim Einlesen bedeutet nicht, dass das Passwort falsch ist: Erst eine ausgeführte Prüfung kann eine Übereinstimmung oder Abweichung feststellen.
Ja, bcrypt verarbeitet bis zu 72 UTF-8-Bytes. Das entspricht bei Umlauten oder Emojis weniger als 72 Zeichen. Dieses Werkzeug lehnt längere Eingaben beim Erzeugen und Prüfen ab. Es kürzt nichts und berechnet auch keinen automatischen Vor-Hash, der die Bedeutung der Eingabe verändern würde.
Noch eine Frage?
Mit „Passwort hashen“ zunächst das passende Beispiel ausführen, dann ein Zeichen ändern und den Unterschied prüfen.
Eine Übereinstimmung ist keine Bewertung der Passwortstärke.