PBKDF2 Generator

More iterations make each password guess slower for an attacker. OWASP's Password Storage Cheat Sheet gives these minimums for PBKDF2 when storing passwords; the tool fills them in when you change the hash.

The salt must be unique for every password and stored next to the result; 16 random bytes is the usual size, and a salt shorter than that triggers a warning. The key length is the number of bytes you need — 32 bytes for an AES-256 key or a SHA-256-sized hash. Asking for more bytes than the hash produces makes PBKDF2 run its whole cost again for each extra block, which slows you down more than an attacker, so match the length to the hash when storing passwords.

To check code against known values, use published test vectors. For example, PBKDF2-HMAC-SHA-256 of the password password with the text salt salt, 1 iteration and 32 bytes gives 120fb6cffcf8b32c43e7225256c4f837a86548c92ccc35480805987cb70be17b. Make sure the salt form matches what your code uses — the text salt and the hex representation of the same bytes are different inputs.

PBKDF2 is widely supported and approved by NIST, but it needs little memory, so graphics cards can test many guesses in parallel. For new password storage, Argon2id is the stronger choice, and bcrypt is also better than PBKDF2 at the same cost. PBKDF2 remains the right choice where FIPS compliance or broad compatibility is required, such as in the Web Crypto API itself.

The derivation runs in your browser with the built-in Web Crypto API. The password and salt are never stored or sent. For password hashing with modern algorithms, see the Argon2 Hash Generator and the Bcrypt Generator; to encrypt data with a PBKDF2-derived key, use AES Encryption.