Skip to main content

PBKDF2 Hash Generator

Derive cryptographic keys from passwords using PBKDF2 with configurable iterations, salt and hash function.

Geprüft von · Zuletzt geprüft

Einen Schlüssel aus einem Passwort ableiten

  1. Tippe das Passwort in das Passwortfeld. Das ist das niedrig-entropische menschliche Geheimnis, das du zu einem vollständigen kryptografischen Schlüssel strecken möchtest.
  2. Wähle die Salt-Strategie. Lasse "Auto-generieren" ein, um ein frisches 16-Byte-Zufalls-Salt von crypto.getRandomValues bei jedem Lauf zu erhalten, oder füge ein spezifisches Hex-Salt ein, wenn du einen zuvor gespeicherten Hash zur Überprüfung reproduzieren musst.
  3. Stelle die Iteration-Anzahl ein. 100.000 ist der OWASP-Mindestboden für PBKDF2-HMAC-SHA-256; 600.000 ist die OWASP-Empfehlung 2023; 1.300.000 entspricht der aktuellen Produktionseinstellung von 1Password.
  4. Wähle Schlüssellänge und Hash-Funktion. 32 Bytes (256 Bits) gepaart mit SHA-256 ist der korrekte Standard für die Ableitung von AES-256-Schlüsseln; 64 Bytes mit SHA-512, wenn du eine längere Ausgabe benötigst, die in mehrere Unterschlüssel aufgeteilt wird.
  5. Klicke auf "Hash generieren". Der abgeleitete Schlüssel-Hex erscheint neben dem Salt-Hex. Beide werden zur Überprüfung benötigt - speichere sie zusammen, genauso wie eine bcrypt-Zeichenkette Kosten, Salt und Hash in einem Feld speichert.

Wie PBKDF2 ein schwaches Passwort in einen starken Schlüssel verwandelt

PBKDF2 ist in RFC 8018 Abschnitt 5.2 (PKCS #5 v2.1) spezifiziert und von NIST SP 800-132 genehmigt. Die Konstruktion nimmt Passwort P und Salt S und berechnet F(P, S, c, i) = U_1 XOR ... XOR U_c, wobei U_1 = HMAC(P, S || INT(i)) und U_j = HMAC(P, U_{j-1}). Die Iteration-Anzahl c zwingt einen Angreifer, die HMAC-Kette für jeden Kandidaten zu wiederholen; das Salt verhindert Rainbow-Table-Vorberechnung. Die Implementierung verwendet crypto.subtle.importKey('raw', passwordBytes, 'PBKDF2', false, ['deriveBits']) dann crypto.subtle.deriveBits({ name: 'PBKDF2', salt, iterations, hash }, keyMaterial, keyLength * 8). Das native Krypto des Browsers (BoringSSL, NSS) führt HMAC-SHA-256 bei etwa 200 MB/Sek. aus, sodass 600.000 Iterationen etwa 100 Millisekunden dauern. Diese Verzögerung ist der Punkt: multipliziert mit Milliarden von Kandidaten-Passwörtern wird Offline-Brute-Force unzumutbar.

Wann PBKDF2 die richtige Wahl ist

  • Benutzerpasswörter in einem System speichern, das einen Datenbankdump überstehen muss. Salt plus iterations-gehärteter Hash bedeutet, dass das LinkedIn-2012-Szenario (6,5 Millionen Passwörter, 90%+ wiederhergestellt) unzumutbar wird.
  • Einen Verschlüsselungsschlüssel aus einer Benutzer-Passphrase für clientseitige Dateiverschlüsselung ableiten (1Password-Vault-Entsperrung, Bitwarden-Schlüsselableitung, LastPass-Vault-Schlüssel).
  • Einen WPA2/WPA3-Personal-Pre-Shared-Key aufbauen: PBKDF2-HMAC-SHA-1 mit 4096 Iterationen ist die IEEE 802.11-Spezifikation.
  • TLS-Pre-Shared-Key-Ableitung für IoT-Geräte, die sich die Komplexität von Argon2 nicht leisten können.
  • Signiertes Cookie-Keying, bei dem der Server den Verschlüsselungsschlüssel aus einer Master-Passphrase rotieren möchte, ohne die Passphrase zu speichern.
  • Regulatorische Compliance mit FIPS-140-3-validierten kryptografischen Modulen - PBKDF2 ist ausdrücklich genehmigt; Argon2 ist noch nicht auf der FIPS-genehmigten Liste.

Iteration-Anzahlen, Salt-Wiederverwendung und Bereitstellungs-Fallstricke

Der häufigste PBKDF2-Fehler ist das Hardcoding der Iteration-Anzahl bei der Bereitstellung und die Nichtaktualisierung. Die OWASP-Empfehlung 2010 waren 10.000 für SHA-1; bis 2023 waren es 600.000 für SHA-256, weil GPUs 60-mal schneller wurden. Wenn deine App 2026 noch 10.000 Iterationen verwendet, knackt ein gemieteter RTX-5090 ein 10-Zeichen-Passwort in Stunden. Der Fix ist ein aktualisierbarer Kostenparameter, der neben dem Hash gespeichert wird; bei erfolgreicher Anmeldung, wenn die gespeicherte Zahl unter der aktuellen Richtlinie liegt, neu ableiten und aktualisieren. Zweiter Fallstrick: Salt-Wiederverwendung - wenn jeder Benutzer dasselbe Salt bekommt, werden Rainbow-Tables machbar. Salt muss pro Benutzer und mindestens 16 Bytes von einem CSPRNG sein. Dritter: Middleware, die Passwörter bei 72 Bytes (bcrypt-Gewohnheit) oder an Unicode-Grenzen kürzt, verursacht Kollisionen zwischen verschiedenen langen Passwörtern. NIST SP 800-132 erfordert mindestens 8-Byte-Salt; der moderne Konsens sind 16 Bytes.

RFC 8018 PBKDF2, NIST SP 800-132 und die Passwort-Hashing-Landschaft

PBKDF2 ist der Elder Statesman: RFC 2898 (2000) dann RFC 8018 (PKCS #5 v2.1, 2017), genehmigt von NIST SP 800-132. Seine Schwäche gegenüber modernen Alternativen ist Parallelisierung: HMAC allein ist trivial GPU/ASIC-parallelisierbar. bcrypt (1999) führte sequenzielle Speichermuster ein, die GPU-Portierung bestrafen. scrypt (RFC 7914) fügte Speicherhärte hinzu - 128 MB RAM pro Versuch macht Cracking-Rigs teuer. Argon2 (PHC-Gewinner 2015, RFC 9106) ist der Stand der Technik mit drei Varianten: Argon2d, Argon2i und Argon2id (OWASP-2024-Empfehlung). OWASPs 2024-Cheat-Sheet rangiert sie Argon2id > scrypt > bcrypt > PBKDF2. PBKDF2 bleibt akzeptabel, weil es in jeder stdlib und FIPS-genehmigt ist; verwende Argon2id, wenn du kannst.

PBKDF2 im Browser vs. CLI vs. nativen Bibliotheken

Der Web Crypto deriveBits-Pfad hier erzeugt identische Ausgabe zu openssl kdf -kdfopt digest:SHA256 -kdfopt pass:"mypassword" -kdfopt hexsalt:... -kdfopt iter:600000 -keylen 32 PBKDF2 oder hashlib.pbkdf2_hmac("sha256", password, salt, 600000, 32) in Python. Die Browser-Implementierung hat einen praktischen Vorteil: sie läuft auf dem Gerät des Benutzers, sodass das Passwort niemals den Server berührt - genau die Architektur, die 1Password und Bitwarden für die Vault-Entsperrung verwenden. Für serverseitige Passwortüberprüfung verwende bcrypt-, argon2- oder phc-crypto-Bibliotheken, statt PBKDF2 von Hand zu rollen. Nie in purem JavaScript rollen: naive Implementierungen lecken Timing durch nicht-zeitkonstante ===-Vergleiche.

Häufig gestellte Fragen

Warum dauert das Werkzeug bei 600.000 Iterationen einen merklichen Moment?

Diese Pause ist die gesamte Sicherheitseigenschaft. PBKDF2-HMAC-SHA-256 bei 600.000 Iterationen auf einem typischen Laptop läuft in etwa 100-300 Millisekunden. Ein Angreifer mit einem GPU-Cluster muss noch proportionale Zeit pro Kandidaten-Passwort verbringen; selbst bei 1.000 GPUs sind das Hunderttausende von Kandidaten pro Sekunde pro Gerät, aber ein 16-Zeichen-Zufallspasswort hat 10^30 Möglichkeiten. Die Verzögerung ist so kalibriert, dass die legitime Anmeldung instant ist, während Offline-Cracking wirtschaftlich unzumutbar wird. Wenn deine App bei 600k Iterationen träge wirkt, ist der Fix ein serverseitiger Worker oder WebWorker-Thread, nicht die Iteration-Anzahl zu senken.

Wie viele Iterationen sollte ich tatsächlich in der Produktion im Jahr 2026 verwenden?

OWASPs 2024 Passwort-Speicher-Cheat-Sheet empfiehlt 600.000 Iterationen für PBKDF2-HMAC-SHA-256, 210.000 für PBKDF2-HMAC-SHA-512 und 1.300.000 für PBKDF2-HMAC-SHA-1 (wenn du damit feststeckst). Große Consumer-Vaults laufen höher: 1Password verwendet 650.000, Bitwarden standardmäßig 600.000 und lässt Benutzer erhöhen, LastPass wechselte nach dem Verstoß 2022 auf 600.000. Zielu auf 500ms Ableitungszeit auf deinem schlechtesten legitimen Client-Gerät und lass das die Zahl bestimmen; 600k ist ein vernünftiger Ausgangspunkt.

Ist das automatisch generierte Salt wirklich zufällig?

Ja. Das Salt sind 16 Bytes von crypto.getRandomValues, das der Browser an den OS-CSPRNG bindet (getrandom auf Linux, BCryptGenRandom auf Windows, SecRandomCopyBytes auf macOS). Das ist dieselbe Zufälligkeitsquelle, die für TLS-Sitzungsschlüssel verwendet wird, und ist für kryptografisches Salt geeignet. 16 Bytes (128 Bits) liegen weit über dem 8-Byte-Minimum von NIST SP 800-132 und sind über jede realistische Benutzerpopulation kollisionsfrei - du müsstest 2^64 Salts generieren, bevor eine Kollision wahrscheinlich ist.

Kann ich einen zuvor gespeicherten PBKDF2-Hash mit diesem Werkzeug überprüfen?

Ja. Deaktiviere die automatische Salt-Generierung, füge das Hex-Salt aus deinem gespeicherten Datensatz ein, stelle Iterationen und Hash-Algorithmus so ein, dass sie exakt übereinstimmen, und gib das Kandidaten-Passwort ein. Wenn der abgeleitete Hash byte-für-byte mit dem gespeicherten übereinstimmt, ist das Passwort korrekt. Parameter müssen genau übereinstimmen: SHA-256 vs. SHA-512 erzeugt andere Ausgabe; 99.999 vs. 100.000 Iterationen erzeugen andere Ausgabe; 32-Byte- vs. 64-Byte-Schlüssellänge erzeugt unterschiedliche Ausgabenlänge. Für zeitkonstante Vergleiche im Produktionscode vergleiche Hashes nie mit einfachem Gleichheitscheck; verwende den Timing-sicheren Vergleich einer Krypto-Bibliothek.

Warum gilt PBKDF2 noch als in Ordnung, wenn Argon2 existiert?

PBKDF2 ist für die meisten Bedrohungsmodelle ausreichend und in der Standardbibliothek jeder Sprache plus der Web Crypto API. Argon2 ist besser, weil sein speicherhartes Design (128 MB RAM pro Versuch bei Standardeinstellungen) GPU- und ASIC-Angriffe etwa 1000-mal teurer macht. Wenn dein Stack Argon2id unterstützt (Node: argon2-Paket, Python: argon2-cffi, Go: golang.org/x/crypto/argon2, PHP: eingebaut), verwende es. PBKDF2 bleibt die richtige Wahl, wenn du FIPS-140-3- Compliance benötigst (Argon2 ist noch nicht FIPS-genehmigt), wenn du Schlüssel in einem Browser ableitest (Argon2 ist nicht in Web Crypto), oder wenn du mit Legacy-Protokollen wie WPA2 interoperieren musst.

Wird mein Passwort irgendwo hin geschickt?

Nein. crypto.subtle.importKey umschließt die Passwort-Bytes in ein CryptoKey-Objekt, das im Krypto-Modul des Browsers bleibt. deriveBits läuft lokal in der nativen Krypto-Implementierung. Kein Fetch, kein XHR, kein Service-Worker-Intercept. Trenne das Netzwerk nach dem Laden der Seite und das Werkzeug funktioniert weiterhin. Wenn du ein Passwort für ein Produktionssystem hashst, denke daran, dass der Klartext noch über HTTPS deinen Server erreichen muss - das Hash-at- Rest-Design schützt nur gegen Datenbankdurchsickerungen, nicht gegen Netzwerkkompromittierungen.

Warum HMAC innerhalb von PBKDF2 statt rohem Hash?

HMAC (RFC 2104) ist eine schlüsselbasierte Hash-Konstruktion, die Längenerweiterungsangriffe auf Merkle-Damgard-Hashes verhindert. PBKDF2 verwendet das Passwort als HMAC-Schlüssel und das Salt als Nachricht und iteriert, um den abgeleiteten Schlüssel aufzubauen. Die Verwendung von rohem SHA-256(Passwort || Salt || Zähler) wäre anfällig für Längenerweiterung. RFC 8018 spezifiziert HMAC aus gutem Grund.

Kann ich den Ausgabe-Hex direkt als AES-Schlüssel verwenden?

Ja. 32 Bytes PBKDF2-Ausgabe ist ein gültiger AES-256-Schlüssel. Konvertiere den Hex zu einem Uint8Array und übergib ihn an crypto.subtle.importKey mit dem Algorithmus AES-GCM. Das ist genau, wie das Begleit-AES-Werkzeug auf dieser Website seinen Schlüssel aus einem Passwort ableitet. Verwende keine PBKDF2-Ausgabe sowohl als Verschlüsselungsschlüssel als auch als HMAC-Schlüssel - leite zwei Unterschlüssel ab, indem du die Schlüssellänge auf 64 Bytes setzt und aufteilst, oder verwende HKDF.

Mehr Security & Privacy

AES-256 Encrypt / Decrypt Online - Free, In-Browser

Encrypt and decrypt text with AES-128, AES-192, or AES-256 in GCM, CBC, or CTR mode. PBKDF2 key derivation, entirely in your browser.

Open tool

Basic Auth Header Generator

Create HTTP Basic Authentication headers from a username and password or API token.

Open tool

CSP Header Generator

Build Content-Security-Policy headers with a visual form, presets and per-directive configuration.

Open tool

Password Entropy Calculator

Estimate password entropy, character pool size and crack-time ranges for online and offline attacks.

Open tool

Password Generator

Generate cryptographically secure random passwords with configurable length, character types and entropy display.

Open tool

Password Strength Checker

Check password strength with entropy calculation, pattern detection and common password matching.

Open tool