Cybersecurity glossary
What is PBKDF2?
Learn what PBKDF2 is, how iteration counts slow password guessing, where it still appears in standards, and when to prefer Argon2 or scrypt for password storage.
Definition
PBKDF2 (Password-Based Key Derivation Function 2) is a standardized key-derivation function that repeatedly applies a pseudorandom function such as HMAC to a password and salt, producing a derived key whose computation cost scales with an iteration count.
Why PBKDF2 still shows up everywhere
Many protocols and enterprise stacks standardized on PBKDF2 long before memory-hard password hashing was mainstream. You will find it in disk-encryption passphrase stretching, older password verifiers, WPA-era designs, and APIs that expose PKCS #5 helpers.
Understanding PBKDF2 matters even if your next service chooses Argon2: migration, compliance documents, and third-party integrations still depend on correct salts, PRFs, and iteration budgets.
What PBKDF2 combines
Password input
A user secret that is usually low entropy compared with random keys.
Unique salt
Random per-derivation bytes that defeat identical-hash collisions and simple rainbow tables.
Iteration count
A tunable work factor that multiplies CPU cost for each guess.
PRF such as HMAC-SHA-256
The repeating building block that mixes password and salt into derived output.
How PBKDF2 derives a key
Collect password and salt
The application supplies the password and a stored or newly generated salt.
Run the PRF loop
PBKDF2 repeatedly applies HMAC (commonly) to stretch the password into blocks.
Produce derived bytes
Output length can be a password verifier digest or an encryption key of required size.
Store or use the result
Password systems store salt, parameters, and verifier; encryption systems feed the key into a cipher.
Verify by recomputation
Logins recompute PBKDF2 with the stored salt and compare in constant time.
Raise cost over time
Rehash on successful login when policy increases iterations.
PBKDF2 compared with modern password KDFs
PBKDF2 is iteration-hard. Attackers with GPUs can still parallelize guesses efficiently unless counts are extremely high.
| KDF | Hardness focus | Practical guidance |
|---|---|---|
| PBKDF2 | CPU iterations | Acceptable if required; keep counts aggressive and salts unique |
| bcrypt | CPU adaptive cost | Fine when already deployed with strong cost |
| scrypt | Memory + CPU | Stronger against parallel guessing than plain PBKDF2 |
| Argon2id | Memory + time + lanes | Preferred default for new password storage |
Operational checklist
- Never deploy PBKDF2 without a unique per-password salt.
- Document the PRF (for example HMAC-SHA-256) and iteration count in the stored encoding.
- Benchmark login latency before freezing parameters.
- Reject trivially low iteration counts in security reviews.
- Prefer Argon2id for new password verifiers unless a standard mandates PBKDF2.
- If deriving encryption keys from passphrases, combine with authenticated encryption and key wrapping.
- Plan transparent upgrades so old PBKDF2 hashes can migrate after successful authentication.
- Pair any password KDF with MFA and online rate limiting.
Where teams misuse PBKDF2
The most common failure is treating “we use PBKDF2” as sufficient while leaving iterations in the low thousands for years. Another is using PBKDF2 as a general-purpose KDF for high-entropy key material where HKDF is more appropriate. PBKDF2 shines at stretching weak passwords—not at expanding already-strong keying material from a TLS handshake.
The practical takeaway
PBKDF2 is the classic iteration-based password KDF. Keep salts unique and work factors high when you must use it, and prefer memory-hard algorithms such as Argon2id for new password storage whenever policy allows.
Related security terms
Argon2
A memory-hard password hash preferred for many new deployments.
bcrypt
An adaptive password hash commonly compared with PBKDF2.
scrypt
A memory-hard KDF that raises GPU cracking costs differently than PBKDF2.
Key Derivation Function (KDF)
The broader family of extract-and-expand and password-based KDFs.
Salt (Cryptography)
Per-password randomness required for PBKDF2 safety.
Frequently asked questions
What is PBKDF2 in simple terms?
PBKDF2 turns a password into a cryptographic key or password verifier by repeating a keyed hash many times with a salt, so guessing passwords offline becomes slower.
Is PBKDF2 still recommended for password storage?
It remains acceptable in some standards and legacy systems when iteration counts are high enough, but OWASP generally prefers Argon2id for new password storage because PBKDF2 is not memory-hard.
What iteration count should I use?
Choose the highest count that keeps authentication latency acceptable on your hardware, and raise it over time. Stale low counts such as a few thousand iterations are no longer adequate.
Does PBKDF2 need a salt?
Yes. Use a unique high-entropy salt per password or key derivation. Reused salts enable precomputation across users.
Can PBKDF2 derive encryption keys from passphrases?
Yes. That is a primary design goal in PKCS #5. Still protect the derived key and consider whether a memory-hard KDF better matches your threat model.
How does PBKDF2 differ from HMAC?
HMAC is the usual pseudorandom function inside PBKDF2. PBKDF2 wraps repeated HMAC (or another PRF) with salt and iteration control for password-based derivation.
Should I migrate away from PBKDF2?
If you already store PBKDF2 password hashes, you can rehash to Argon2id on login. For new greenfield password databases, prefer Argon2id unless a standard forces PBKDF2.
References
Explore authoritative guidance and frameworks related to pbkdf2.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.