PBKDF2 - Password-Based Key Derivation
About 2 min read
PBKDF2 (Password-Based Key Derivation Function 2) is a function for securely deriving a cryptographic key from a password. By repeatedly applying a hash function tens of thousands to hundreds of thousands of times, it raises the computational cost and resists brute-force attacks. It was published by RSA Laboratories in 2000 as PKCS #5 v2.0 and standardized in NIST SP 800-132. It is a long-established algorithm built into a wide range of systems, including Wi-Fi WPA2 and macOS disk encryption.
Historical Background
PBKDF1, the predecessor of PBKDF2, was defined in PKCS #5 v1.5 in 1993, but it had the problem that the derivable key length was limited to the output length of the hash function. PBKDF2, published in 2000, removed this restriction and made it possible to derive keys of arbitrary length. In 2010 it was formally standardized as NIST SP 800-132, and its use came to be recommended even in U.S. government systems. While it has a long history and a broad track record of adoption, the limits of its security have come to be pointed out as GPUs have advanced.
HMAC-Based Iterative Computation
The internal structure of PBKDF2 is simple. It repeatedly applies HMAC (Hash-based Message Authentication Code) using the password and a salt as input.
The output of each iteration is accumulated with XOR to generate the final key. As of 2025, OWASP recommends at least 600,000 iterations with HMAC-SHA256. When using HMAC-SHA512, at least 210,000 iterations are recommended.
Adoption in Wi-Fi WPA2
The most familiar example of PBKDF2 in use is Wi-Fi WPA2-Personal (WPA2-PSK). When deriving the actual encryption key from the Wi-Fi password (PSK: Pre-Shared Key), it uses PBKDF2-HMAC-SHA1 iterated 4,096 times. This iteration count was reasonable when it was specified in 2004, but with current GPU performance hundreds of thousands of attempts per second are possible, and short passwords can be cracked in a realistic amount of time. WPA3 has moved to SAE (Simultaneous Authentication of Equals), resolving this problem.
Limitations Today
The biggest weakness of PBKDF2 is that its computation is CPU-bound and consumes almost no memory. GPUs have thousands of compute cores and can execute simple computations like HMAC-SHA256 massively in parallel. With high-performance GPUs as of 2025 (such as the NVIDIA RTX 4090), even 600,000 iterations of PBKDF2-HMAC-SHA256 allow tens of thousands of password candidates to be tried per second.
| Property | PBKDF2 | bcrypt | scrypt | Argon2id |
|---|---|---|---|---|
| Year introduced | 2000 | 1999 | 2009 | 2015 |
| Memory-hard | ✗ | ✗ | ✓ | ✓ |
| GPU resistance | Low | Moderate | High | High |
| NIST standardization | SP 800-132 | None | RFC 7914 | RFC 9106 |
| OWASP recommendation rank | 4th (legacy) | 2nd | 3rd | 1st |
Migration in Practice
In existing systems that use PBKDF2, a gradual migration that re-hashes with Argon2id or bcrypt at the user's next login is common. When migrating a password hash, you need a design that retains the old and new hashes in parallel and verifies both until all users have completed migration. From a key management perspective as well, it is a good opportunity to review the purpose and storage method of the derived key.
"We carried out the migration from PBKDF2 to Argon2id over six months. By adopting a re-hashing approach at login and verifying both hashes during the transition period, we were able to complete it with zero impact on users."
The basics of cryptography are explained in The Basics of Encryption, and the overall picture of password management in The Secure Password Management Guide. For password security in the post-quantum era, please also refer to Post-Quantum Password Security.cryptography and security books on Amazon will help you learn even more deeply.
Common Misconceptions
There is a misconception that "PBKDF2 is the most secure because NIST has standardized it," but standardization is a guarantee of compatibility, not of security. NIST itself recommends the use of memory-hard functions in SP 800-63B, and PBKDF2 is positioned close to the "minimum acceptable line." The idea that "increasing the iteration count can also counter GPUs" is also wrong; because GPUs can execute the same HMAC computation as CPUs in parallel, increasing the iteration count affects legitimate users and attackers equally.
Was this article helpful?