Safeguard
Security Guides•

HKDF or a password hash: which key derivation function to use

HKDF turns strong secret material into keys but is not for passwords. Argon2id, scrypt or PBKDF2 slow down guessing. How to choose for each job.

Safeguard Security Team
3 min read

Use HKDF when your input is already strong, random secret material such as a shared secret from a key exchange or a master key. Use a slow password-based function such as Argon2id, scrypt or PBKDF2 when the input is a human-chosen password. HKDF cannot add entropy or slow down guessing.

What HKDF is for

RFC 5869 describes two stages. Extract compresses input keying material and an optional salt into a fixed-length pseudorandom key. Expand then stretches that key into as many output bytes as you need, bound to an optional context string called info.

That makes it the right tool for:

  • turning one master key into several independent keys, one per purpose
  • deriving encryption and MAC keys from a key exchange result
  • binding a derived key to a protocol, algorithm or user identity through the info field

The salt is not secret and can be reused across derivations. The info field keeps the same input from producing the same key in two contexts.

Why it is wrong for passwords

The RFC is direct: HKDF is not suitable as-is for low-entropy input. Extraction can concentrate entropy but cannot add any, and HKDF has no mechanism to slow brute-force guessing. A password-based scheme is what is needed there.

A password hash like Argon2id is deliberately costly in time and memory so each guess is expensive. See our posts on choosing a password hashing algorithm and storing passwords with Argon2id.

A decision table in words

  • Input is a random 256-bit key and you need several keys: HKDF.
  • Input is a Diffie-Hellman shared secret: HKDF, with extract, and do not skip it.
  • Input is a user password and you need to verify login: Argon2id, scrypt, bcrypt or PBKDF2 with a stored hash.
  • Input is a user password and you need an encryption key: a password-based KDF to make a key-encrypting key. See the passphrase wrapping pattern.

Common mistakes

  • Using one derived key for both encryption and authentication. Derive separate keys with different info strings. Our note on one key, one purpose explains why.
  • Using HKDF with a user PIN. A short PIN has so few possibilities that any fast derivation falls to guessing.
  • Leaving info empty everywhere, so two features derive the same key.
  • Rolling your own derivation with repeated hashing.

Quick check

Can I use HKDF output as a password hash?

No. It is fast by design, so stolen values can be guessed at high speed.

Do I need a salt for HKDF?

It is optional but helpful. A random, non-secret salt strengthens independence between uses, as RFC 5869 describes.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.