PBKDF2 Generator

What this tool does

PBKDF2 Generator derives a key from a password and salt using the RFC 8018 algorithm through the browser’s Web Crypto API, with a configurable pseudorandom function, iteration count and output length. It formats results as raw hex or Base64, or as ready-made Django, Werkzeug and passlib password-hash strings, and can parse and verify a password against any of those stored formats.

PBKDF2 turns a password and a salt into a derived key by running an HMAC construction over and over, thousands or millions of times, so that testing a guess costs an attacker roughly the same amount of work it cost you to create the hash. That repeated-iteration idea, standardised as PKCS #5 and later RFC 8018, underlies password storage in Django, Flask’s Werkzeug, 1Password, WPA2 Wi-Fi handshakes and many VPN and disk-encryption products, which is why you often need to reproduce or check a PBKDF2 value exactly.

This tool calls the Web Crypto deriveBits function with your chosen pseudorandom function, iteration count and output length, accepting the salt as text, hex or Base64 bytes. Once a key is derived it is shown as hex and Base64, and, where the digest length matches, assembled into the exact string format that Django’s pbkdf2_sha256$, Werkzeug’s pbkdf2:sha256: and passlib’s $pbkdf2-sha256$ schemes use, so you can drop the result straight into a user table. The verify mode parses any of those three formats back into its parameters and checks a candidate password with a constant-time comparison.

How to use PBKDF2 Generator

1. Choose “Derive key” mode and enter the password you want to hash.
2. Type a salt, or click Random salt to generate 16 random bytes in hex.
3. Pick the PRF (HMAC-SHA-1, SHA-256, SHA-384 or SHA-512) and set the iteration count, or click the OWASP preset button for a current minimum.
4. Set the desired key length in bytes if you need something other than the hash’s natural output size.
5. Read the derived key in hex and Base64, and copy whichever ready-made hash string format matches your framework.
6. To check a stored hash, switch to “Verify hash string”, paste the full string and the password to test, then click Verify.

Tips for better results

• OWASP’s 2023 guidance calls for 600,000 iterations with HMAC-SHA-256, far more than the older defaults still seen in some codebases; use the preset button rather than guessing a round number.
• A 16-byte random salt per password is enough to defeat precomputed rainbow tables; reusing one salt across every user removes that protection entirely.
• Django, Werkzeug and passlib each store the iteration count inside the hash string itself, so verification always uses the parameters that were current when the hash was created, not today’s default.
• The RFC 6070 test vector button loads known inputs and outputs, which is the quickest way to confirm the tool (or your own implementation) computes PBKDF2 correctly.

Common use cases

• Generating a Django-compatible pbkdf2_sha256$ hash to insert directly into a user table during a data migration.
• Debugging a failed login by re-deriving a key from the salt and iteration count stored alongside a user’s password hash.
• Choosing an iteration count by timing how long derivation takes on representative hardware before deploying a setting to production.
• Learning how PBKDF2’s salt, iteration count and pseudorandom function combine by experimenting with RFC 6070 test vectors.

Common mistakes to avoid

• Deriving a key with HMAC-SHA-1 and a low iteration count just because it was once a common default; current guidance favours SHA-256 or stronger with a much higher count.
• Storing the derived key without also storing the salt and iteration count used to create it, which makes later verification impossible.
• Comparing derived keys with ordinary equality in production code instead of a constant-time comparison, which can leak timing information to an attacker.