PBKDF2 Key Derivation
How it works
PBKDF2 (Password-Based Key Derivation Function 2) is a key stretching algorithm designed to make brute-force attacks expensive. It applies a pseudorandom function (typically HMAC-SHA-256) to a password combined with a salt, iterating the process tens of thousands of times to produce a derived key of any length.
**Why key stretching is necessary** A raw SHA-256 of a password can be computed in nanoseconds. An attacker with a GPU cluster can test billions of passwords per second. With PBKDF2 at 100,000 iterations, each guess takes 100,000× longer. At 1 billion attempts/second on raw SHA-256, only 10,000 attempts/second are possible with PBKDF2-100k — reducing a cracking campaign from hours to centuries for strong passwords.
**Parameters explained** Salt: a random 16-byte value, unique per password, stored alongside the derived key. The salt prevents rainbow table attacks and ensures that two users with identical passwords produce different derived keys. Iterations: NIST recommends ≥ 600,000 for PBKDF2-HMAC-SHA-256 (2023 SP 800-132). Key length: 32 bytes for AES-256, 16 for AES-128. The derived output is deterministic given the same password + salt + iteration count.
**PBKDF2 vs bcrypt vs Argon2** PBKDF2 is parallelizable — GPU attacks scale linearly with hardware. bcrypt is memory-latency bound (64KB scratchpad) making GPU attacks ~10× more expensive. Argon2 (winner of the Password Hashing Competition 2015) allows tuning both time and memory, providing the strongest resistance. For new password storage, prefer Argon2id; PBKDF2 remains correct for key derivation in TLS and disk encryption contexts (PKCS#5, WPA2, iOS keychain).
Frequently Asked Questions
- NIST SP 800-132 (2023) recommends a minimum of 600,000 iterations for PBKDF2-HMAC-SHA-256 for password hashing. As a rule of thumb, tune the iteration count so that key derivation takes 100–300ms on your target hardware — this makes the user experience acceptable while making brute-force attacks expensive. If using for disk encryption (like WPA2 or iOS keychain), higher counts are appropriate since derivation happens only on unlock.
- Using the same salt means two users with identical passwords produce the same derived key. An attacker who compromises the database can then crack both accounts simultaneously with one attack. More dangerously, a rainbow table built for that specific salt can be reused across all users sharing it. Always generate a cryptographically random 16-byte salt independently for each password, and store the salt alongside the derived key.
- For password storage in 2024+, prefer Argon2id (winner of the Password Hashing Competition) — it allows tuning both time cost and memory cost, making GPU/ASIC attacks expensive. bcrypt is memory-latency bound (64KB) and well-supported in most frameworks. PBKDF2 is the weakest of the three against GPU attacks (it is parallelizable with minimal memory) but remains correct for key derivation in protocols like WPA2, TLS, and iOS keychain. Never use unsalted MD5 or SHA-256 for passwords.
- PBKDF2 outputs a derived key of any length. For AES-256 encryption, request 32 bytes. For AES-128, 16 bytes. For HMAC-SHA-256 keys, 32 bytes. The output is deterministic: given identical password + salt + iteration count + key length, you always get the same key — this is the property that enables password-based encryption (encrypt with derived key, rederive on password entry to decrypt).