PBKDF2 Key Derivation

PBKDF2 turns a password into a key by running HMAC over it many thousands of times. The point is not secrecy — the algorithm is public and so is the salt — but cost: an attacker guessing passwords has to pay the same iteration count on every guess. Set the password, the salt, the iteration count, the hash and how many bits you want out, and the derivation runs through the browser's own WebCrypto implementation. Nothing is sent anywhere.

The defaults reproduce the third test vector from RFC 6070: password and salt at 4096 iterations of HMAC-SHA1 gives 4b007901b765489abead49d926f721d065a429c1. That vector is the reason this tool is useful for debugging — if your server and this page disagree on a key, one of you is encoding the password or the salt differently, and a shared reference point tells you which. The salt can be entered as text or as hex, because a salt read from a database is almost never printable.

Iteration counts are a moving target, and the field warns below 100,000 for that reason. OWASP's current password-storage guidance is 600,000 iterations for HMAC-SHA256 and 210,000 for HMAC-SHA512, the difference being that SHA-512 does more work per round on 64-bit hardware. The presets are there so the number is a decision rather than something inherited from a tutorial written a decade ago.

One detail worth knowing about the output length: PBKDF2 produces its key one hash-sized block at a time, so asking for more bits than the hash emits makes it run the whole chain again for each extra block. Requesting 512 bits from HMAC-SHA256 costs exactly twice the work of requesting 256 and gives you nothing stronger, because the security still rests on the same 256-bit function. The tool says so when it happens.

Finally, the honest caveat: PBKDF2 has no memory hardness, so it parallelises cheaply on GPUs and specialised hardware. It remains the right choice where a standard or a platform requires it, and for new password storage Argon2id or scrypt are the better-defended options.