The trap of identical passwords, a pinch of salt

The same password becomes the same hash

A hash always gives the same result for the same input.
That is exactly why, when you enter the same password again,
it can be checked against the stored hash.
But this property casts a shadow.
If two people use the same password,
their two hashes come out the same too.
Just by looking at the stored hash list,
if identical values sit side by side,
you can tell the passwords are the same.
You may not know the password itself, yet the fact that they match leaks out.

Make the two people's passwords same or different. When they match, the hashes show up identical, side by side.

Choosing the same password,
the two hashes looked identical.
Just from the hashes, the sameness shows at once.
Why is that a problem?
We learned a hash is hard to reverse,
but the point that the same value gives the same hash does not change.
So what if someone hashed common passwords
ahead of time and wrote them down?

Why a pre-built table is risky

Commonly used passwords are fewer in kind than you might think.
So such passwords and their hashes
can be written down ahead of time, one line each.
With such a pre-built lookup table on hand,
a stored hash can be searched in the table
and the password guessed back from it.
It is not cracking the hash itself
but matching against answers written in advance.
That is why a common password is more at risk:
it is more likely to already be in the table.

Tap a stored hash. Notice that if the same hash sits in a pre-written table, the password can be guessed back.

When a hash in the table matched the stored hash,
the password in the next cell was laid bare.
A hash not in the table blocked the guess.
Here we can grasp the core.
The root of the risk is that the same password
always becomes the same hash.
So the way to block it appears too.
If the same password is made to hash differently per person,
no single pre-built table can match anymore.
That method is exactly salting.

Add a salt to the password

A salt is a small value set differently for each person.
Instead of hashing the password as is,
you first attach that person's salt to the password.
Then you hash the two combined.
What matters is that the salt differs per person.
A salt is not a secret to hide.
It is fine to store it right beside the hash,
because knowing only the salt
does not let you know the password.
A salt does just one thing: make the hash different per person.

Tap to add each person's salt to the password. The salt is attached to the password, then that combination is hashed.

Adding the salt changed the very input fed into the hash.
Even with the same password,
if the salt attached in front differs,
the ingredients going into the hash differ from each other.
We learned that a hash, with even a tiny change in input,
gives a completely different result.
So if the salts differ, the hashes cannot help but differ.
Now let's directly compare how the stored hashes look
when two people use the same password.

Even the same password becomes a different hash

Recall when there was no salt.
The hashes of two identical passwords were the same.
Turn the salt on and the story changes.
Even if two people's passwords are the same,
the salts differ, so the stored hashes differ from each other.
Now, even looking at the stored hash list,
you cannot pick out who used the same password.
What is more, a pre-built table goes powerless.
That table was made from hashes of unsalted passwords,
so it does not match a salt-mixed hash.
Since the salt differs per person, one would in effect need a separate table for every single person.

Compare with the salt off and on. Off: same password, same hash. On: even the same password gets a different hash, and the table goes powerless.

The moment the salt turned on,
the two once-identical hashes split into different values.
The pre-built table no longer matched either.
One small pinch solved two things at once.
It blocks both telling the same password from stored hashes alone
and tracing common passwords back through a table.
And it does so without hiding any new secret,
just by adding a value that differs per person.
Now let's wrap the whole thing up.

Let's wrap up

Gathered on one line, it is this.
The same password becomes the same hash.
So stored hashes reveal a shared password,
and a pre-built table risks tracing common passwords back.
The fix is to add a per-person salt
to the password before hashing.
A salt is not a secret; it only needs to differ per person.
Add a salt and even the same password gives all different hashes,
so the table goes powerless and identical hashes no longer appear.
Undo the trap with salt, the same password into a different hash. That is salting.

Tap the key points in order to review. (same password is same hash -> the risk of a pre-built table -> add a salt -> even the same password a different hash)

Now you know why the same password becomes a trap,
and how a single pinch of salt
undoes that trap.
It is elegant that without hiding any more secrets,
just by making things differ per person,
the defense grows much sturdier.
This idea of deliberately creating a small difference
you will meet again and again in security.
Next, how do such protections
layer ever more tightly together?
Let's keep exploring together.