Password salting
Also known as: salting, salted hash, password salt, salted password hashing
Password salting is a security technique where a website adds a unique random value, called a salt, to each user's password before hashing it for storage.
Even if two people choose the same password, their stored hashes look completely different, and attackers can't use precomputed tables to crack many passwords at once. While salting is essential, it must be combined with deliberately slow hashing algorithms to truly slow down password cracking.
Password salting, explained at three levels
At home
Salting is like a cook adding a different random spice to each order before blending it into a smoothie. Two people who order the same smoothie still get drinks that taste different. A website does this with passwords: before scrambling each one into a hash, it mixes in a random value called a salt, so identical passwords look completely different in storage, and attackers can't crack them all at once.
At work
Password salting means adding a unique random value, called a salt, to each user's password before it is hashed and stored. The salt is kept beside the hash, but it makes every stored value unique, so attackers who steal the database can't use pre-built lookup tables or crack many identical passwords at once. Combined with slow hashing such as bcrypt or Argon2, it protects customers after a breach.
At home
When a website stores your password, it saves a hash, a one-way fingerprint, rather than the password itself. Without salt, everyone with the password 'sunshine' would have the identical hash, and attackers could look up common ones in huge pre-built tables. A salt is a random value added to each password before hashing. Now two people with the same password have completely different hashes, so the attacker must crack each one separately.
At work
Each account gets its own random salt, typically 16 bytes or more, stored right beside the hash in the database. The salt does not need to be secret; its job is to make each hash unique, which defeats rainbow tables and stops attackers from cracking many accounts with one effort. Modern password hashing functions such as bcrypt, scrypt and Argon2 generate and store the salt automatically, along with a configurable work factor that sets how slow each guess is.
At home
Salting makes cracking slower for attackers, but it does not make a weak password strong. Cracking software still tries common passwords first, so '123456' or your pet's name will fall quickly against any one account, salt or not. Salt protects the crowd, not the individual. In my view, choosing a long, unique password is still your own job, whatever the website does with it behind the scenes.
At work
Use a vetted password hashing library, never a homemade combination of salt and a fast hash. Argon2id is the current recommendation, with memory and iteration settings tuned so a login takes a fraction of a second on your hardware. A pepper, a secret added to every password and kept outside the database, such as in a hardware security module, means a database-only breach cannot be cracked. When upgrading algorithms, rehash each password transparently the next time its owner logs in.
Real-world examples
At home
Aisha read a breach notice saying passwords were 'salted and hashed.' She still changed hers, but understood it would be much harder for attackers to recover.
At work
Marcus is a developer at a Winnipeg startup. During a code review, he replaced a homemade password storage method with Argon2, which salts and slows hashing automatically.
How it compares
| feature | Salted hash | Unsalted hash |
|---|---|---|
| Identical passwords | Different stored values | Same stored value |
| Rainbow table attacks | Ineffective | Effective |
| Cracking many at once | Much harder | Easy |
| Recommended | Yes, with slow hashing | Never |
Salting forces attackers to crack passwords one by one.
For analysts
When reviewing software or vendors that store passwords, I'd confirm they use a modern algorithm such as bcrypt or Argon2. It's a quick question that reveals a lot about security maturity.
History & origin
Robert Morris and Ken Thompson described salting in a 1979 paper on Unix password security, adding a 12-bit salt to protect against precomputed attacks. Precomputed 'rainbow tables,' popularized by Philippe Oechslin in 2003, showed how unsalted hashes could be cracked quickly. Niels Provos and David Mazières introduced bcrypt in 1999, combining salting with adjustable slowness. In 2012, a leak of about 6.5 million LinkedIn password hashes, stored with unsalted SHA-1, saw most cracked quickly, and the full breach later turned out to involve about 117 million accounts. Argon2 won the Password Hashing Competition in 2015 and became a recommended modern choice. In my view, the LinkedIn breach is the definitive lesson in why salting and slow hashing aren't optional.