Salt & Key Derivation
Turn a human password into a real key — and never twice the same.
What it does
This site is named for the thing this page is about. A salt is a pinch of randomness mixed into a secret before it's hashed — and it's one half of how a short, guessable password becomes a real cryptographic key.
The problem: a password like swordfish is short, low-entropy, and human. A key needs to be long, uniform, and unguessable. A key-derivation function (KDF) bridges the gap. PBKDF2 — the one built into your browser — does it with two ideas: a salt, and a deliberately slow grind.
Two problems salt solves
Hashing a password without salt looks fine until you notice what determinism leaks:
- Identical passwords collide. Hash
hunter2and you always get the same digest — so two users who picked the same password store the same value, and a leak reveals that they match. - One table cracks everyone. An attacker hashes the million most common passwords once into a rainbow table, then reverses any unsalted hash with a lookup. The work is done ahead of time, against all victims at once.
A unique random salt per password kills both. The same password now hashes to a different value every time, so nothing collides — and a precomputed table is worthless, because the attacker would need a separate table for every possible salt, and there are 2¹²⁸ of them.
Same password, different key
Below, Alice and Bob type the same password — but each has their own salt, so each derives a completely different key. Edit the password (it applies to both) or roll a new salt and watch the keys stay stubbornly distinct:
…
…
…
…
deriving…
The only difference between the two lanes is the salt. That's why an attacker can't precompute one table of password→key and reuse it: every salt needs its own table, and there are 2¹²⁸ of them.
The work factor: slow on purpose
Salt stops precomputation, but it doesn't stop someone guessing passwords one by one. That's the second idea: a KDF is deliberately slow. PBKDF2 repeats its inner hash tens of thousands of times — the demo above runs 100,000 rounds for a single derivation.
The asymmetry is the whole point. You pay that cost once, when you log in, and never notice a few milliseconds. An attacker testing billions of guesses pays it billions of times, and the wall becomes impassable. As hardware speeds up, you simply raise the iteration count. Newer KDFs — Argon2, scrypt, bcrypt — go further and burn lots of memory too, which blunts the custom-chip attacks that make plain hashing cheap to brute-force.
Salt is not a secret
A salt is stored right next to the hash, in the clear — it's not a key, and it doesn't need hiding. Its only job is to be unique, so each derivation stands alone. (A separate secret value mixed in and kept server-side is sometimes called a pepper — different tool, different page.)
A fast hash is the wrong tool here
SHA-256 is built to be fast — exactly what you want for integrity, and exactly what you don't want for passwords, where speed helps the attacker. Reaching for a plain hash to store passwords is the classic mistake. The fix is this page's slow, salted derivation — which is the foundation of password storage, up next.
What it's for
- Disk & file encryption — your passphrase is stretched into the AES key that unlocks the drive. The encryption demo on this site does exactly this with PBKDF2.
- Password managers — one master password derives the vault key, slowly, so a stolen vault resists offline cracking.
- Password storage — the same salted, slow grind is what a login system keeps instead of your password.