What is password salting

The same password gives the same hash

A hash always gives the same result for the same input. That is what let us compare the fingerprint of a login attempt with the stored fingerprint. But this property casts a shadow.
If two people use the same password, their hashes come out the same too. When identical values sit side by side in the stored hash list, the fact that the two passwords match leaks out, even if the password itself does not. If one person's password becomes known, so does the password of everyone with the same hash.

Choose the two people's passwords to be the same or different. When the passwords match, the stored hashes show up identical, side by side.

Choosing the same password made the two hashes identical. The match shows at a glance from the hashes alone. We learned that a hash cannot be calculated backward, but the fact that the same value gives the same hash does not change.
So what happens if someone hashes common passwords in advance and writes them down in a list?

Why is a pre-built table dangerous?

The passwords people commonly use come in fewer varieties than you might think. So it is possible to build a table that lists such passwords with their hashes, one per line, in advance. With a table like that, the hashes from a breached store can be looked up and the original passwords read off at once.
It does not crack the hash backward; it matches against answers written down in advance. The especially dangerous part is that a single table can be matched against huge numbers of hashes at once. A cleverly compressed version of such a table is called a rainbow table.

Tap the stored hashes one at a time. If the same hash is in the pre-written table, the password is exposed; if it is not, the guess is blocked.

Hashes that matched the table exposed the password in the next column, while a hash not in the table blocked the guess. The root of the danger is that the same password always becomes the same hash.
That also shows the way to block it. If the same password hashes differently for each person, no single pre-built table can match anymore. That method is the salt.

Add a salt to the password

A salt is a short value chosen at random for each person. It is created when the person signs up, and instead of hashing the password as it is, the system attaches that person's salt and hashes the combination.
A salt is not a secret, so it is stored right next to the hash. The same salt has to be attached again at login to get the same fingerprint. A salt does one job: it makes the hash different for each person.

Press the add-salt button. The two people have the same password, but their salts differ, so the combined inputs and the hashes come out different.

Adding the salt changed the input going into the hash. Even with the same password, a different salt means different ingredients, and a hash changes completely when its input changes even slightly. So different salts can only mean different hashes.
Now let's turn the salt off and on to compare how the stored hashes of two people with the same password look.

Even the same password gives a different hash

Without salt, the two identical passwords had identical hashes. With salt, the stored hashes differ even though the two passwords are the same. Looking at the hash list no longer tells you who shares a password.
The pre-built table loses its power too. It was made from unsalted passwords, so it does not match salted hashes. To use a table, an attacker would have to build a new one for every salt, which means for every person, so in practice it becomes useless.

Turn the salt off and on to compare. Off, the same password gives the same hash; on, even the same password gives different hashes and the pre-built table no longer matches.

When the salt went on, the two identical hashes split into different values, and the pre-built table stopped matching. One small pinch blocked two things at once: spotting shared passwords from stored hashes, and looking up common passwords in a table.
A salt does not stop everything, though. An attacker can still target one person, attach that person's salt to common passwords and try them one by one. That is why salt has to be combined with a deliberately slow hash and long passwords that are hard to guess.

Wrapping up

In short, the same password gives the same hash, so stored hashes can reveal shared passwords and a pre-built table can look up common passwords. To prevent this, a random salt, different for each person, is attached to the password before hashing.
A salt is not a secret; it only needs to differ from person to person. With salt, even the same password gives different hashes, and pre-built tables lose their power.

Tap the key points in order to review. (same password, same hash → the danger of a pre-built table → add a salt for each person → even the same password, a different hash)

Now you know why the same password is a trap and how a pinch of salt closes it. It is striking that the defense grows stronger without hiding any new secret, just by making each person's value different.
So far we have looked at how to store passwords safely. But is a password alone enough to prove who you are? The next lesson, on authentication, covers the many ways besides passwords to show that you are you. A password is only something you know; something you have and something you are can serve as proof too.