PBKDF2 Hash Generator

Deriving a Key from a Password

1. Type the password into the password field. This is the low-entropy human secret you want to stretch into a full cryptographic key.
2. Choose the salt strategy. Leave "Auto-generate" on to get a fresh 16-byte random salt from crypto.getRandomValues on every run, or paste a specific hex salt when you need to reproduce a previously stored hash for verification.
3. Set the iteration count. 100,000 is the minimum OWASP floor for PBKDF2-HMAC-SHA-256; 600,000 is the 2023 OWASP recommendation; 1,300,000 matches 1Password\'s current production setting.
4. Pick key length and hash function. 32 bytes (256 bits) paired with SHA-256 is the correct default for deriving AES-256 keys; 64 bytes with SHA-512 if you need a longer output split into multiple subkeys.
5. Click "Generate Hash". The derived key hex appears alongside the salt hex. Both are needed for verification - store them together, same as a bcrypt string stores cost, salt, and hash in one field.

How PBKDF2 Turns a Weak Password into a Strong Key

PBKDF2 is specified in RFC 8018 section 5.2 (PKCS #5 v2.1) and approved by NIST SP 800-132. The construction takes password P and salt S and computes F(P, S, c, i) = U_1 XOR ... XOR U_c where U_1 = HMAC(P, S || INT(i)) and U_j = HMAC(P, U_{j-1}). The iteration count c forces an attacker to repeat the HMAC chain for every candidate; the salt prevents rainbow-table precomputation. The implementation uses crypto.subtle.importKey('raw', passwordBytes, 'PBKDF2', false, ['deriveBits']) then crypto.subtle.deriveBits({ name: 'PBKDF2', salt, iterations, hash }, keyMaterial, keyLength * 8). The browser\'s native crypto (BoringSSL, NSS) runs HMAC-SHA-256 at around 200MB/sec, so 600,000 iterations takes around 100 milliseconds. That delay is the point: multiplied by billions of candidate passwords, offline brute force becomes infeasible.

When PBKDF2 Is the Right Call

• Storing user passwords in a system that needs to survive a database dump. Salt + iteration-hardened hash means the LinkedIn 2012 scenario (6.5M passwords, 90+ percent recovered) becomes infeasible.
• Deriving an encryption key from a user passphrase for client-side file encryption (1Password vault unlock, Bitwarden key derivation, LastPass vault key).
• Building a WPA2/WPA3-Personal pre-shared key: PBKDF2-HMAC-SHA-1 with 4096 iterations is the IEEE 802.11 spec.
• TLS pre-shared key derivation for IoT devices that cannot afford the complexity of Argon2.
• Signed cookie keying where the server wants to rotate the encryption key from a master passphrase without storing the passphrase.
• Regulatory compliance with FIPS 140-3 validated cryptographic modules - PBKDF2 is explicitly approved; Argon2 is not yet on the FIPS-approved list.

Iteration Counts, Salt Reuse, and Deployment Pitfalls

The most common PBKDF2 mistake is hardcoding iteration count at deploy time and never updating it. The 2010 OWASP recommendation was 10,000 for SHA-1; by 2023 it was 600,000 for SHA-256 because GPUs got 60x faster. If your app still uses 10,000 iterations in 2026, a rented RTX 5090 cracks a 10-character password in hours. The fix is an upgradeable cost parameter stored alongside the hash; on successful login, if the stored count is below current policy, re-derive and update. Second pitfall: salt reuse - if every user gets the same salt, rainbow tables become viable. Salt must be per-user and at least 16 bytes from a CSPRNG. Third: middleware that truncates passwords at 72 bytes (bcrypt habit) or at Unicode boundaries causes collisions between different long passwords. NIST SP 800-132 requires at least 8-byte salt; modern consensus is 16 bytes.

RFC 8018 PBKDF2, NIST SP 800-132, and the Password-Hashing Landscape

PBKDF2 is the elder statesman: RFC 2898 (2000) then RFC 8018 (PKCS #5 v2.1, 2017), approved by NIST SP 800-132. Its weakness relative to modern alternatives is parallelism: HMAC alone is trivially GPU/ASIC parallelizable. bcrypt (1999) introduced sequential memory patterns that punish GPU porting. scrypt (RFC 7914) added memory-hardness - 128MB RAM per guess makes cracking rigs expensive. Argon2 (PHC winner 2015, RFC 9106) is state of the art with three variants: Argon2d, Argon2i, and Argon2id (OWASP 2024 recommendation). OWASP\'s 2024 cheat sheet ranks them Argon2id > scrypt > bcrypt > PBKDF2. PBKDF2 remains acceptable because it is in every stdlib and FIPS-approved; use Argon2id when you can.

PBKDF2 in the Browser vs CLI vs Native Libraries

The Web Crypto deriveBits path here produces identical output to openssl kdf -kdfopt digest:SHA256 -kdfopt pass:"mypassword" -kdfopt hexsalt:... -kdfopt iter:600000 -keylen 32 PBKDF2 or hashlib.pbkdf2_hmac("sha256", password, salt, 600000, 32) in Python. The browser implementation has one practical advantage: it runs on the user\'s device, so the password never touches the server - exactly the architecture 1Password and Bitwarden use for vault unlock. For server-side password verification, use bcrypt, argon2, or phc-crypto libraries rather than hand-rolling PBKDF2. Never roll your own in pure JavaScript: naive implementations leak timing through non-constant-time === comparison.