PBKDF2 online - Schlüsselableitung

Leiten Sie einen kryptografischen Schlüssel aus einem Passwort mit PBKDF2-HMAC direkt im Browser ab. Konfigurieren Sie Hashfunktion (SHA-1, SHA-256, SHA-384 oder SHA-512), Iterationen, Ausgabelänge und Salt. Im Verify-Modus vergleichen Sie ein Kandidatenpasswort mit einem vorhandenen PBKDF2-Hexwert.

Salt (leer für zufällig)
Passwort
0 Zeichen · 0 Bytes
Hash zur Überprüfung
Ausprobieren:
Ergebnis
✓ Verarbeitung erfolgt lokal im Browser ✓ Eingaben werden nicht an den Server gesendet
Beispiele
Typisches Passwort
Hash-Funktion: SHA-256 Iterationen: 600000 Schlüssellänge (Bytes): 32
Eingabe passwort123

Ein typisches Benutzerpasswort. Klicken Sie auf Compute, um mit den aktuellen Einstellungen einen Schlüssel abzuleiten.

Passphrase
Hash-Funktion: SHA-256 Iterationen: 600000 Schlüssellänge (Bytes): 32
Eingabe richtiges pferd batterie klammer

Eine lange Passphrase ist leichter zu merken und hat meist mehr Entropie als ein kurzes Passwort.

PBKDF2-HMAC-SHA512
Hash-Funktion: SHA-512 Iterationen: 210000 Schlüssellänge (Bytes): 64 Salt (leer für zufällig): docs-example-salt
Eingabe release-notizen-geheimnis

Verwendet SHA-512, eine Ausgabe von 64 Bytes und einen festen Beispiel-Salt für reproduzierbare Dokumentation oder Interoperabilitätstests.

Hohe Iterationskosten
Hash-Funktion: SHA-256 Iterationen: 1000000 Schlüssellänge (Bytes): 32 Salt (leer für zufällig): login-user-42-unique-salt
Eingabe passphrase fuer adminbereich

Ein PBKDF2-HMAC-SHA256-Lauf mit einer Million Iterationen zum Vergleichen der Latenz und zum Prüfen reproduzierbarer Parameter.

Was ist PBKDF2?

PBKDF2 (Password-Based Key Derivation Function 2) ist ein Algorithmus zur Schlüsselableitung aus Passwörtern, beschrieben in RFC 2898 und standardisiert in NIST SP 800-132. Er nimmt ein Passwort, einen Salt, eine Iterationszahl, eine Pseudozufallsfunktion wie HMAC-SHA256 und eine Ausgabelänge und erzeugt daraus einen deterministischen kryptografischen Schlüssel.

Der Algorithmus ist absichtlich rechenintensiv: Jede Iteration wiederholt die HMAC-Arbeit, sodass jeder Passwortversuch mehr Zeit kostet. Dieses PBKDF2-Online-Tool nutzt die Web Crypto API des Browsers und erzeugt den Hex-Schlüssel lokal, ohne Passwort oder Salt an den Server zu senden.

PBKDF2 wird für Passwortspeicherung, verschlüsselte Dateiformate, Wallet-Backups, API-Testdaten und kompatible Systeme genutzt, in denen PBKDF2-HMAC-SHA256 oder PBKDF2-HMAC-SHA512 durch ein bestehendes Protokoll vorgegeben ist.

PBKDF2 vs bcrypt vs Argon2

PBKDF2 ist die portabelste Option zur Schlüsselableitung: Es ist in Browsern, OpenSSL, Java, .NET, Python, Node.js, Betriebssystem-APIs und vielen Compliance-orientierten Umgebungen verfügbar. Deshalb eignet es sich für interoperables Passwort-Hashing, Legacy-Migrationen und Systeme, die PBKDF2_HMAC- oder pbkdf2_sha256-Kompatibilität benötigen.

Die Schwäche von PBKDF2 ist, dass es CPU-gebunden ist und praktisch keine Speicherkosten hat. Angreifer mit GPUs und ASICs können PBKDF2-Versuche viel effizienter parallelisieren als Verteidiger auf normalen Applikationsservern.

bcrypt widersteht GPU-Angriffen besser, weil es einen kleinen internen Speicherzustand nutzt. Argon2id ist die moderne Standardwahl für neue Passwortspeicherung, da es memory-hard und gut einstellbar ist. Wählen Sie Argon2id, wenn Sie den Stack kontrollieren; wählen Sie PBKDF2, wenn Kompatibilität, Web-Crypto-Unterstützung, FIPS-orientierte Umgebungen oder bestehende Protokolle wichtiger sind.

PBKDF2-Parameter: Hash, Salt, Iterationen, Schlüssellänge

Dieser PBKDF2-Generator zeigt die Parameter, die Entwickler meistens benötigen. Die Hash-Einstellung wählt den HMAC-Digest als Pseudozufallsfunktion: SHA-256 ist der praktische Standard, SHA-512 ist in SHA-2-Umgebungen verbreitet, SHA-384 ist für Kompatibilität verfügbar, und SHA-1 sollte nur für Legacy-Formate verwendet werden.

Der Salt sollte für jedes Passwort oder jeden abgeleiteten Schlüssel eindeutig sein. Er muss nicht geheim sein; speichern Sie ihn zusammen mit dem abgeleiteten Hash oder den verschlüsselten Daten. In Produktionssystemen sollte der Salt aus einer kryptografisch sicheren Zufallsquelle stammen. Ein fester Salt ist nur für reproduzierbare Beispiele und Testvektoren sinnvoll.

Iterationen steuern die Kosten. Höhere Werte verlangsamen sowohl legitime Prüfung als auch Offline-Raten. Der Standardwert ist 600.000 Iterationen für PBKDF2-HMAC-SHA256 und entspricht der OWASP-2024-Basisempfehlung. Die Schlüssellänge ist die Ausgabelänge in Bytes: 32 Bytes ergeben einen 256-Bit-Schlüssel und ein 64-stelliges Hex-Ergebnis; 64 Bytes ergeben eine 512-Bit-Ausgabe.

PBKDF2 erzeugen, prüfen und speichern

Verwenden Sie den Hash-Modus, um aus einem Passwort und den gewählten Parametern einen PBKDF2-Hexwert zu erzeugen. Verwenden Sie Verify, wenn bereits ein gespeicherter PBKDF2-Hexwert vorliegt: Das Tool leitet den Schlüssel erneut mit demselben Salt, Hash, derselben Iterationszahl und Schlüssellänge ab und meldet, ob die Werte übereinstimmen.

PBKDF2 kann nicht entschlüsselt werden. Es ist eine Einwegfunktion zur Schlüsselableitung; eine Prüfung funktioniert nur, indem das Kandidatenpasswort mit den ursprünglichen Parametern erneut berechnet und das Ergebnis verglichen wird. Ändert sich Salt, Hashfunktion, Iterationen oder Schlüssellänge, ändert sich auch der abgeleitete Wert.

Für echte Benutzerkonten sollte Passwort-Hashing auf dem Anwendungsserver mit gepflegter Bibliothek, Rate Limiting, Monitoring und einem Plan für Parameter-Upgrades erfolgen. Dieser PBKDF2-Online-Rechner eignet sich vor allem zum Lernen, Debuggen von Interoperabilität, Dokumentieren von Parametern, Erstellen reproduzierbarer Testvektoren und Prüfen eines Hashes während der Entwicklung.

FAQ

OWASP 2024 empfiehlt 600.000 Iterationen für PBKDF2-HMAC-SHA-256 und 210.000 für PBKDF2-HMAC-SHA-512. NIST SP 800-132 nennt mindestens 1.000, was heute nur eine sehr niedrige Untergrenze ist. Der richtige Wert hängt von Bedrohungsmodell und Hardware ab: Zielen Sie auf etwa 100-500 ms auf Ihrem Server. Mehr Iterationen bremsen Angreifer proportional; weniger Iterationen reduzieren die Latenz für Nutzer.

Ein Salt ist ein eindeutiger Zufallswert, der vor der Ableitung zum Passwort gehört. Ohne Salt erzeugen gleiche Passwörter gleiche Hashes, wodurch Rainbow-Table-Angriffe praktikabel werden. Mit einem eindeutigen Salt pro Nutzer muss ein Angreifer jeden Hash separat angreifen. Der Salt muss nicht geheim sein, nur eindeutig; 16 zufällige Bytes sind in der Regel ausreichend. Speichern Sie den Salt zusammen mit dem Hash.

Wählen Sie PBKDF2, wenn breite Plattformunterstützung, FIPS-Validierung oder Interoperabilität mit Legacy-Systemen erforderlich ist. Für neue Systeme ist Argon2id normalerweise besser, sofern verfügbar. PBKDF2 hat keine Speicherkosten, deshalb können Angreifer es günstig auf GPUs parallelisieren. Für Anwendungen mit hohen Sicherheitsanforderungen ist Argon2id die empfohlene Wahl.

Nein. PBKDF2 wird vollständig im Browser über die Web Crypto API (window.crypto.subtle.deriveBits) berechnet. Passwort und Salt verlassen Ihr Gerät nicht: keine Netzwerkrequests, kein Logging, keine serverseitige Verarbeitung.

Nein. PBKDF2 ist keine Verschlüsselung und hat keine Entschlüsselungsoperation. Es ist eine Einwegfunktion zur Schlüsselableitung. Um ein Passwort zu prüfen, berechnen Sie PBKDF2 erneut mit demselben Salt, derselben Hashfunktion, Iterationszahl und Schlüssellänge und vergleichen den neuen Hexwert mit dem gespeicherten Wert.

Verwenden Sie PBKDF2-HMAC-SHA256, sofern kein Protokoll oder vorhandener Datenbestand eine andere Option verlangt. PBKDF2-HMAC-SHA512 ist ebenfalls verbreitet, besonders in Systemen, die bereits SHA-512 nutzen. SHA-384 ist für Kompatibilität verfügbar. Verwenden Sie SHA-1 nicht für neue Designs; behalten Sie es nur für Legacy-Formate, die PBKDF2-HMAC-SHA1 ausdrücklich verlangen.

Speichern Sie den abgeleiteten Hash, Salt, Iterationszahl, Hashfunktion und Schlüssellänge. Die PBKDF2-Ausgabe allein reicht für spätere Prüfung nicht aus, weil der Verifier exakt dieselben Parameter wiederholen muss. Viele Systeme kodieren diese Felder in einer Zeichenkette; andere speichern sie in separaten Spalten.

Nein. Der Salt muss eindeutig und möglichst zufällig sein, ist aber kein geheimer Schlüssel. Er sorgt dafür, dass gleiche Passwörter unterschiedliche PBKDF2-Ausgaben erzeugen, und verhindert die Wiederverwendung vorberechneter Tabellen. Speichern Sie den Salt neben dem Hash.

Nutzen Sie ihn für Lernen, Parametervergleiche, Interoperabilitätsprüfungen und Testvektoren. Für Produktionskonten sollten PBKDF2-Berechnung und Prüfung auf dem Server erfolgen, mit sicheren zufälligen Salts, Rate Limiting, Monitoring und kontrollierten Parameter-Upgrades. Browserseitiges Hashing allein ersetzt keine serverseitigen Schutzmaßnahmen für Passwortspeicherung.
Verwandte Tools

HMAC-Generator

HMAC aus Text und einem geheimen Schlüssel direkt im Browser erzeugen.