Glossary
What is a salt? The per-user 'seasoning' added to a password hash
A salt is a random value, different for each user, added before a password is hashed. Why it's needed (the same password stores differently for everyone, defeating rainbow tables and bulk reuse cracking), how it differs from a pepper, and common misconceptions — explained defensively, no attack steps.
"Salt" comes up the moment you talk about password hashing. Like salt in cooking, adding a pinch to the hash changes the safety picture dramatically. Here's how it works and the key points (no attack steps).
Why the "seasoning" works
Without a salt, users with the same password get the same stored hash. That hands an attacker two shortcuts: a precomputed lookup table (a rainbow table) lands directly, and "cracking one account reuses across everyone with the same password."
Add a salt and the same "password123" stores as something completely different for each user.
Common misconceptions vs the truth
Misconception
- A salt must be kept secret
- One shared salt for all users is fine
- A salt makes even weak passwords safe
The truth
- A salt can be public (store it with the hash)
- A different random value per user (ideally per password)
- A salt defends "precomputation and reuse cracking"; brute force is handled by a slow hash
This site's view: a salt is not a pepper
Often confused with a salt is a pepper: a secret value added across the board, kept somewhere other than the database (app config or a key manager). A salt (public, per-user) and a pepper (secret, global) have different jobs — neither substitutes for the other. In practice, though, the first priority is simply using salt + a slow hash correctly via bcrypt/Argon2.
Read next
- Glossary: what password hashing is (understand it together with salt)
- Learn: how to store passwords safely (hashing + salt in practice)
- Basics: storing passwords the right way
FAQ
QDoes a salt have to be kept secret?
No. A salt is not a 'secret key' — it's fine to store it next to the hash. Its purpose isn't secrecy; it's to make the same password store differently for every user, which defeats precomputation (rainbow tables) and bulk reuse cracking. The thing you keep secret is a different concept, a 'pepper' (see below).
QCan I reuse the same salt for all users?
No. The salt must be a random value that differs per user (ideally per password). A shared salt makes users with the same password store identical hashes, so an attacker can break many accounts with a single brute-force run. Generate a fresh one with a cryptographic RNG each time.
QDo I need to implement the salt myself?
Usually not. Purpose-built hashes like bcrypt, Argon2, and scrypt generate and store the salt for you (often embedded inside the hash string). Rather than adding a salt by hand, lean on these standard implementations — it's safer and more reliable.