The One Sentence Definition
A salt is a random value added to a password before it's hashed, so that even identical passwords produce completely different hashes. It's stored alongside the hash, and its job is to make precomputed cracking attacks useless. Think of it as a unique pinch of randomness mixed into each password's fingerprint.
The Problem Salt Solves
Websites store password hashes, not passwords (our hashing guide explains why). But hashing alone has a weakness: the same password always produces the same hash. So if two users both choose "password123", their hashes are identical, and attackers can exploit this:
- Rainbow tables: precomputed lists of millions of common passwords and their hashes. Steal a database, look up each hash in the table, done. No cracking needed for common passwords.
- Spotting reuse: identical hashes reveal which users share a password, and cracking one cracks them all.
How Salt Fixes It
Add a unique random salt to each password before hashing:
hash("password123" + "x7Fq2mZ") = a1b2c3...
hash("password123" + "9kLp4Wn") = d4e5f6... (same password, totally different hash!)Now:
- Rainbow tables are useless. The precomputed table would need to include every possible salt, making it astronomically large: not feasible.
- Identical passwords hide. Two users with "password123" have different hashes, so reuse is invisible and each must be cracked individually.
- Attackers must crack one password at a time, the slow way, instead of looking everything up at once.
The salt isn't secret: it's stored right next to the hash. Its power isn't secrecy, it's uniqueness: it forces attackers to do fresh work for every single password.
Salt doesn't make a weak password strong. "password123" salted is still crackable individually. What salt does is stop the attacker from cracking a million accounts in one lookup. It turns a bulk attack back into a grind.
Salt vs Pepper (Bonus)
You may hear of a "pepper": similar idea, but the pepper is a secret value stored separately from the database (in application config or an HSM), applied to all passwords. If the database leaks but the pepper doesn't, even salted hashes gain extra protection. Salt (unique, stored with the hash) and pepper (secret, stored apart) work together in careful implementations.
The Modern Reality
Today you rarely add salt manually: proper password hashing algorithms (bcrypt, scrypt, Argon2) generate and handle salts automatically, and are also deliberately slow to resist brute force (our brute force guide). If you're a developer, the rule is simple: never hash passwords with plain fast hashes like MD5 or SHA-256 (our SHA-256 vs MD5 comparison), and never roll your own salting. Use a purpose-built algorithm and let it manage salts for you.
Frequently Asked Questions
If the salt is stored with the hash, how does it help?
Because it doesn't need to be secret to work. Its purpose is to make each hash unique, defeating precomputed tables and forcing per-password cracking. An attacker sees the salt but still can't reuse work across accounts, which is the whole point.
Does salting protect my weak password?
Only against bulk attacks. A salted "123456" is still trivially crackable on its own; salt just prevents it being cracked alongside a million others instantly. Your defence against individual cracking is a long, unique password (our generator) plus 2FA.
Should each user have a different salt?
Yes, and each password should really get its own unique salt (modern algorithms do this per-hash automatically). A shared salt across all users would still let attackers build one table for that salt, undermining the benefit.
What's the difference between salt and encryption?
Different jobs. Salt is used with hashing (one-way, for password storage). Encryption is reversible with a key (for protecting data you need to read back). Salting a password isn't about being able to decrypt it: passwords are never decrypted, only re-hashed and compared.
As a regular user, do I need to do anything about salt?
No: salting happens server-side, invisibly, and is the website's responsibility. Your job is choosing strong, unique passwords and enabling 2FA. Salt is one reason a well-built site's breach is less catastrophic, but you can't control whether a site salts properly, which is exactly why unique passwords matter: so one site's bad practices don't sink your other accounts.
