KDFs & Password Hashing

Why this module exists

Passwords and shared secrets are low-entropy inputs that attackers can brute force offline. Key derivation functions (KDFs) exist to turn weak or structured secrets into strong, application-specific keys while making attacks expensive. Many real-world breaches come from weak KDF parameters or misuse of salts and peppers.

This module teaches the difference between KDFs for protocols (HKDF) and KDFs for passwords (PBKDF2, scrypt, Argon2), how to choose parameters, and how to encode and verify password hashes safely.

1) Hashes vs KDFs vs password hashing

A cryptographic hash is fast and deterministic. That is the opposite of what you want for password storage. Password hashing should be slow and configurable, so brute force is expensive.

• Hash: fast, fixed function. Good for integrity, not for passwords.
• KDF: transforms input keying material into one or more keys.
• Password hashing KDF: deliberately expensive for offline attackers.

2) Threat model: offline guessing

Assume the attacker steals your database and can test guesses locally. The defense is to maximize the cost per guess, while keeping login latency acceptable. That is the fundamental trade-off.

Key levers:

• Iterations (time cost)
• Memory cost (scrypt/Argon2)
• Parallelism (how many cores used per hash)

3) Salts and peppers

• Salt: random, unique per password, stored with the hash. Prevents precomputed rainbow tables and ensures identical passwords hash differently.
• Pepper: secret, shared value stored separately (e.g., in an HSM or config). Adds a second secret so database theft alone is not enough.

Salt is not secret. Pepper is secret.

4) HKDF (protocol KDF)

HKDF is designed for cryptographic key derivation, not password hashing.

Two phases:

1. Extract: PRK = HMAC(salt, IKM)
2. Expand: OKM = HMAC(PRK, T(0) || info || 0x01) || ...

Why it matters:

• Turns weak or biased input into pseudorandom key material.
• Separates contexts using the info string (domain separation).
• Used heavily in TLS 1.3 and other protocols.

5) PBKDF2 (password KDF)

PBKDF2 repeatedly applies HMAC to make guessing expensive.

For block i:

U1 = HMAC(password, salt || INT_32_BE(i))
U2 = HMAC(password, U1)
...
Uc = HMAC(password, Uc-1)
Ti = U1 XOR U2 XOR ... XOR Uc

Output is the concatenation of Ti blocks.

PBKDF2 is CPU-hard but not memory-hard, so GPUs/ASICs can accelerate it. Use a high iteration count and consider memory-hard KDFs for stronger defense.

6) Memory-hard KDFs (scrypt/Argon2)

Memory-hard KDFs force attackers to allocate large memory per hash. This makes parallel cracking expensive and reduces GPU advantage.

• scrypt: older but widely supported.
• Argon2: modern standard (Argon2id recommended).

If you can choose today, Argon2id is usually the best default.

7) Parameter selection and upgrades

KDF parameters are not static. You should:

• Store parameters with the hash.
• Raise cost over time as hardware improves.
• Support rehashing on login when parameters are outdated.

Practical strategy:

• Decide a target login latency (e.g., 50-200 ms).
• Benchmark on production hardware.
• Increase cost until you hit the target.

8) Constant-time comparison

When verifying a password hash, avoid early-exit comparisons. Timing leaks can reveal how many bytes match. Use constant-time comparisons even for hashes.

What you will build

1. HMAC-SHA256: the PRF at the core of many KDFs.
2. HKDF: extract and expand key material safely.
3. PBKDF2: iterative password hashing.
4. Password hash verification: parse parameters, apply pepper, and compare in constant time.

Key takeaways

• Password hashing is about offline attacker cost.
• Salts stop precomputation; peppers add a second secret layer.
• HKDF is for protocol keys, PBKDF2/scrypt/Argon2 for passwords.
• Parameters must be stored and upgraded over time.