If attackers can store databases of common passwords, even variations on common passwords and password schemes, how can we protect them?
Salt is used to dramatically increase the difficulty of reversing a hashed password that doesn’t rely on the user changing the complexity of their password.
You say “potato”, I say “cvswrfPotato”
In order to beat the hash cracking methods we have discussed, passwords are now stored with a piece of random data that we call salt. When someone sets their password,
P, we generate a salt,
S, randomly. We store
- The vertical bar denotes concatenation. So
grilled|cheese = grilledcheese
- The comma just shows we have two separate items
When someone tries to log in, we take their password attempt,
Q, and prepend the stored salt,
S. If this matches the stored hash, we have some confidence that the person providing
Q is a
Reversing Salted Hashes
Now, our attacker has a much bigger problem. Using lists of known hashes no longer works. Someone who has the password “HappyDays” actually might have the hash for “sdfhgjHappyDays” stored. So if the hash list contains the hash for “HappyDays”, it still can’t identify the password that was salted. However…
- Brute force attacks using common passwords still works if the attacker has access to the list of hashes
- If the password we are trying to find from a hash is a common one, then trying the top 10,000 passwords is trivial
- We just need to try each one with the known salt
Read the article on Rainbow tables in the See also section below.
We have only discussed their use in reversing hashes, but rainbow tables exist to speed up the decryption of mobile phone calls and other kinds of communication. What do you think are the best general steps to take to defend against this type of attack?
© Coventry University. CC BY-NC 4.0