PBKDF2 Hash Generator

What this tool is used for

• Deriving an encryption key from a passphrase so the key is not the passphrase itself.
• Matching an existing system's stored parameters when migrating or verifying a login.
• Measuring how long a given iteration count actually takes on target hardware before choosing one.
• Producing a fixture that exercises a key-derivation path with known parameters.
• Deriving a fixed-length key for a cipher that requires an exact key size.

Frequently Asked Questions

What does PBKDF2 do that a plain hash does not?

It is deliberately SLOW. Repeating the hash tens of thousands of times makes each guess expensive, which is the entire defence — a fast hash like SHA-256 lets a GPU try billions of passwords per second.

How many iterations should I use?

OWASP currently recommends 600,000 for PBKDF2-HMAC-SHA256 and 210,000 for SHA-512. The number must rise over time as hardware improves, which is why the iteration count is stored alongside the hash.

Why does the salt need to be unique?

Because a shared salt lets one precomputed table attack every password at once. A unique random salt per user — 16 bytes is standard — means each password must be attacked independently, and identical passwords produce different hashes.

Is PBKDF2 still a good choice?

It is acceptable and FIPS-approved, which is why it persists in regulated environments. But it is not memory-hard, so GPUs and ASICs parallelise it cheaply. Argon2id is the current recommendation, with scrypt as a second choice.

Is the salt secret?

No — it is stored in plaintext alongside the hash and that is by design. Its job is uniqueness, not secrecy. A secret value added separately is called a pepper and is stored outside the database.

Why does the output length matter?

Requesting more output than the underlying hash produces makes PBKDF2 run the whole iteration count again per block, so asking for 512 bits from HMAC-SHA256 doubles the defender's cost without doubling the attacker's. Keep the length at or below the hash size.

Does PBKDF2 resist GPU and ASIC attacks?

Poorly — it needs almost no memory, so a GPU runs thousands of instances in parallel. That is the specific weakness Argon2 and scrypt were designed to fix by making each guess require a large working set.

Common errors and gotchas

• Using an iteration count copied from a decade-old tutorial. The number must track hardware, and old defaults are now trivial.
• Reusing one salt across users, which lets a single precomputed attack cover all of them at once.
• Treating the salt as a secret. It is not, and it must be stored alongside the derived value to verify anything.
• Requesting more output than the underlying hash produces, which costs extra work without adding security.
• Choosing PBKDF2 for new password storage when a memory-hard function resists GPUs far better.