Salt

A hash always gives the same output for the same input — perfect for fingerprinting a file, but a problem for passwords. If two people both choose “password123”, their hashes come out identical, and an attacker who has seen that hash once will recognise it everywhere. Salt is the fix.

How a website should store your password

A responsible website never stores your actual password. It stores a hash of it. When you log in, it hashes whatever you typed and checks it against the stored hash. So a data breach leaks hashes, not passwords — and because hashing is one-way, those hashes can’t be turned back into the words you chose. This is why the way a site handles passwords matters more than almost anything else it does.

The rainbow-table problem

But attackers plan ahead. They pre-compute the hashes of millions of common passwords into a lookup table (a “rainbow table”). If everyone’s “password123” hashes to the same value, a single lookup cracks all of them at once — and it also reveals that two accounts share a password, which is how a leak at one site becomes a key to another.

Salt: a pinch of randomness

A salt is a random value mixed into each password before it’s hashed. Alice’s “password123” plus her unique salt hashes to something completely unlike Bob’s “password123” plus his. Now every stored hash is one-of-a-kind: rainbow tables are useless, and identical passwords no longer look identical. The salt itself isn’t secret — it’s stored right next to the hash. Its only job is to make each hash unique.

Step by step: signing up

Here’s the whole flow the next time you join a site like Facebook:

1. You enter a username and password and hit sign up. The password travels to the server over an encrypted connection.
2. The server immediately runs your password — plus a fresh random salt — through a hash function. It never writes your actual password down.
3. Only your username, the salt, and the resulting hash are saved to the database. Your real password is thrown away; even the company can’t read it back.
4. When you log in later, the server hashes what you typed with the same salt and compares it to the stored hash. A match lets you in — it checked fingerprints, never the password itself.
5. If attackers steal the whole database, they get a pile of salted hashes, not passwords. One-way and uniquely salted, the hashes can’t be reversed or matched across sites — the difference between “reset your password as a precaution” and outright catastrophe.

Salt keeps stored secrets unique — but it doesn’t make guessing any slower, and a modern graphics card guesses very fast indeed. The companion trick is to make each guess deliberately expensive.

Key takeaways

• Websites should store a hash of your password, not the password — a breach then leaks hashes, not passwords.
• A salt (random value added before hashing) makes every hash unique, defeating rainbow tables and stopping one breach from unlocking your other accounts.

Check yourself

Why store a hash of your password rather than the password itself?

It’s fasterA breach then exposes only hashes, which can’t be reversed to your passwordIt saves spaceThe law requires it

What does adding a salt achieve?

It encrypts the passwordIt makes identical passwords hash differently, defeating precomputed rainbow tablesIt speeds up loginIt backs up the password