Category: Passwords & Hashing

PBKDF2

Also known as: PBKDF2, Password-Based Key Derivation Function 2

Simply put

PBKDF2 is a method for turning a password into a cryptographic key or a securely stored password hash. It works by repeatedly applying a pseudorandom function to the password combined with a random value called a salt, which makes it much harder for attackers to guess passwords using precomputed tables or dictionary lists. It is widely used to protect stored passwords.

Formal definition

PBKDF2 (Password-Based Key Derivation Function 2) is a password-based key derivation function specified in RFC 2898 (PKCS #5). It derives a key from a password by applying a pseudorandom function (commonly HMAC) to the password together with a salt over a number of iterations; the length of the derived key is essentially unbounded per the specification. The salt and iteration count are intended to increase resistance to dictionary attacks and rainbow table (precomputed hash) attacks. In practice it is used both for deriving cryptographic keys from passwords and for storing password verifiers. Note that PBKDF2's security depends heavily on configuration, particularly the iteration count and the choice of underlying pseudorandom function; specific parameter recommendations are out of scope for this evidence.

Why it matters

PBKDF2 addresses a foundational problem in identity systems: storing passwords in a way that resists attack if the password store is compromised. A plain or unsalted hash of a password can be reversed at scale using precomputed lookup tables (rainbow tables) or dictionary lists. By combining the password with a random salt and applying a pseudorandom function over many iterations, PBKDF2 forces an attacker to expend meaningful computational effort per password guess and defeats precomputation, since each stored verifier is individualized by its salt. This makes it a widely adopted mechanism for protecting stored password verifiers and for deriving keys from passwords.

Because it is specified in RFC 2898 (PKCS #5) and has been available for a long time, PBKDF2 is broadly supported across cryptographic libraries, platforms, and compliance regimes, which is a large part of its continued relevance. Organizations that need an interoperable, standardized, and well-understood password-hashing option frequently encounter PBKDF2 as a default or approved choice.

Its protective value is not automatic, however. PBKDF2's security depends heavily on configuration, particularly the iteration count and the choice of underlying pseudorandom function. An implementation using a low iteration count offers substantially weaker resistance to offline guessing than one tuned appropriately for current hardware. Teams that treat PBKDF2 as a set-and-forget primitive rather than a parameterized function that must be reviewed over time may find their stored verifiers weaker than assumed. Specific parameter recommendations are out of scope for this entry.

Who it's relevant to

IAM engineers and system administrators

Those responsible for how credentials are stored and verified will encounter PBKDF2 as a common option for password hashing. They should understand that its effectiveness depends on the configured iteration count and the underlying pseudorandom function, and that salts and iteration counts are typically stored alongside the derived output to support later verification.

Security architects

Architects selecting a password-protection or key-derivation approach may choose PBKDF2 for its standardization under RFC 2898 (PKCS #5) and broad library support. They should weigh its configuration-dependent strength and treat parameters as values that require periodic review rather than fixed defaults.

Compliance officers and auditors

Reviewers assessing how an organization protects stored passwords will often see PBKDF2 cited as an approved or default mechanism. Because its resistance to dictionary and rainbow table attacks hinges on configuration, particularly iteration count and pseudorandom function choice, auditors should confirm that concrete parameters are documented and justified rather than accepting the use of PBKDF2 as sufficient on its own.

Inside PBKDF2

Password-Based Key Derivation Function

PBKDF2 is a key derivation function that transforms a password (or passphrase) into a cryptographic key, and is commonly used for password hashing when storing credentials at rest. It is defined in the PKCS #5 family of specifications (also published as an RFC), though you should verify the exact version and RFC number against the primary source before citing it.

Salt

A per-credential random value combined with the password input so that identical passwords produce different derived outputs. Salting defends against precomputed lookup and rainbow-table attacks; the salt is typically stored alongside the derived value and need not be secret.

Iteration Count (Work Factor)

A configurable number of internal repetitions of the underlying operation that deliberately increases the computational cost of deriving each key. Raising the iteration count slows down brute-force and dictionary attacks, and the appropriate value depends on hardware and threat model at deployment time.

Underlying Pseudorandom Function (PRF)

PBKDF2 is built on a PRF, commonly an HMAC construction using a hash such as SHA-256, which is invoked repeatedly according to the iteration count. The specific PRF is a configuration choice that affects the properties of the output.

Derived Key Length (dkLen)

A parameter specifying the desired length of the output key material. PBKDF2 can produce output of a requested length independent of the underlying hash's native digest size.

Common questions

Answers to the questions practitioners most commonly ask about PBKDF2.

Is PBKDF2 an encryption algorithm?

No. PBKDF2 is a password-based key derivation function, not an encryption algorithm. It applies a pseudorandom function (typically HMAC with an underlying hash such as SHA-256) iteratively to derive a fixed-length output from a password and salt. It does not encrypt data, and its output cannot be reversed to recover the input password. When used for password storage, it produces a derived value that is verified by recomputation, not decrypted.

Does using PBKDF2 mean my stored passwords are safe from cracking?

Not by itself. PBKDF2 slows down guessing attacks by increasing the computational cost per candidate password, but its protection depends heavily on configuration and context. A low iteration count, a missing or reused salt, or weak underlying passwords all reduce its effectiveness. In addition, PBKDF2 is comparatively friendly to parallelized attacks on GPUs and specialized hardware because it is not memory-hard, unlike memory-hard functions such as scrypt or Argon2. Whether it is adequate depends on your threat model and configuration.

How should I choose the iteration count for PBKDF2?

The iteration count is typically selected to make each derivation take an acceptable amount of time on your production hardware while remaining tolerable for legitimate authentication latency. Higher counts raise attacker cost but also raise your own per-verification cost. Because guidance and hardware capabilities change over time, many deployments periodically revisit this value and increase it. The specific number that is appropriate depends on your environment; consult current authoritative guidance rather than relying on a fixed figure.

How do I handle salts with PBKDF2?

In most password-storage deployments, a unique, sufficiently long random salt is generated per credential and stored alongside the derived output. The salt prevents identical passwords from producing identical derived values and defeats precomputed lookup tables. The salt is not secret and does not need to be encrypted; its purpose is uniqueness. Some designs additionally use a separate secret value (sometimes called a pepper) kept outside the database, but that is a distinct mechanism from the salt and is out of scope for PBKDF2 itself.

Which underlying hash function should PBKDF2 be configured with?

PBKDF2 is defined to use an underlying pseudorandom function, most commonly HMAC with a hash such as SHA-256 or SHA-512. The choice affects the output size and the per-iteration cost. Deployments should select a well-regarded, current hash rather than a deprecated one, and record the chosen PRF as part of the stored parameters so verification can be reproduced. The exact selection depends on your platform's available primitives and applicable compliance requirements.

How can I migrate from PBKDF2 to a memory-hard function like Argon2 without forcing password resets?

A common approach is to store the algorithm identifier and parameters with each credential so multiple schemes can coexist. On successful authentication, the plaintext password is available momentarily and can be re-derived under the new function, and the stored value updated in place. Credentials for users who have not authenticated remain under PBKDF2 until their next successful login. This lets you transition gradually without mass resets, though the specifics depend on your storage format and how parameters are versioned in your deployment.

Common misconceptions

PBKDF2 encrypts passwords, so they can be decrypted if needed.

PBKDF2 is a one-way key derivation function used for password hashing, not an encryption scheme. There is no key to reverse it; verification is done by recomputing the derived value from the supplied password and comparing, not by decrypting a stored value.

A single fixed iteration count set once is sufficient forever.

The protection PBKDF2 provides against brute-force attacks depends on the work factor relative to available attacker hardware. Because compute capacity increases over time, the iteration count typically needs periodic review and increases, and existing stored values may need to be upgraded on next successful authentication depending on your deployment.

PBKDF2 is memory-hard and therefore resistant to GPU and ASIC acceleration like some newer functions.

PBKDF2 is primarily CPU-cost based and is not memory-hard, so it can be more susceptible to parallelized hardware attacks than memory-hard alternatives. Whether PBKDF2 or a memory-hard function is the better choice depends on your requirements, constraints, and any applicable compliance guidance; treat this as configuration- and context-dependent.

Best practices

Use a unique, sufficiently random salt for every stored credential and store it alongside the derived output; do not reuse a single global salt.

Set the iteration count as high as your latency and hardware budget reasonably allow, and revisit it periodically, increasing it over time as compute capacity grows.

Choose the underlying PRF deliberately (for example an HMAC with a modern hash) and document the PRF, iteration count, salt length, and derived key length as part of your credential storage scheme.

Verify passwords by recomputing the derived value and using a constant-time comparison, rather than treating the stored value as something reversible.

Provide a mechanism to transparently rehash credentials with updated parameters on the next successful authentication so existing stored values can be upgraded over time.

Confirm the exact specification version, RFC number, and any applicable compliance requirements against primary sources before standardizing on specific parameters, and evaluate memory-hard alternatives where your threat model and constraints call for them.