2
votes

I wish to ask a question about just how effective salting is if a web user chooses an incredibly easy-to-guess password. I have read (and re-read) the following webpages, but I feel my understanding is still not 100% clear.

Salt and passwords

How does password salt help against a rainbow table attack?

From the second of the URLs above, the following can be found (courtesy of user "Ross"):

To understand the first one, imagine a single password file that contains hundreds of usernames and passwords. Without a salt, I could compute "md5(attempt[0])", and then scan through the file to see if that hash shows up anywhere. If salts are present, then I have to compute "md5(salt[a] . attempt[0])", compare against entry A, then "md5(salt[b] . attempt[0])", compare against entry B, etc. Now I have n times as much work to do, where n is the number of usernames and passwords contained in the file.

Now, I understand that the introduction of a unique salt to each record in the table makes it n-times more difficult for the hacker to hack the passwords. But what if the web user is naive enough to have "password" or "dog" or "cat" as his password? If I understand the StackOverflow answers correctly, each unique salt for each record in a database table is not kept secret. A hacker who manages to breach the database can easily individual salts. The salts are MEANT to slow down a hacker because a hacker would need n rainbow tables instead of one rainbow table. BUT, if a web user has the password cat, and this web user happens to be the first or second or third record in a 10000-record long table, then

               $hash = sha512($salt.cat)

will not protect the naive web user from being hacked, will it? Because the hacker KNOWS the salt, and he might append or prepend the salt to an easy password, and he will know the hash. And he will then use a rainbow table and the web user's data is compromised. Am I right in understanding that the POSITION of a web user's record in a table, and the simplicity of a web user's chosen password, can undermine even the most ingenious hash because the hacker has access to the salt?

2
The answer of Ross, which you linked, starts with "...A public salt will not make dictionary attacks harder when cracking a single password...". The salt "slows down" cracking the entire database. The cost of cracking one single password remains (approximately) the same with or without salt.inquisitive
Understood, and thanks!Arnold Pine
As you said, a salt will only prevent to get all passwords at once with a single rainbowtable, it doesn't help if an attacker brute-forces a single password. To thwart brute-forcing you need a slow hash algorithm with a cost factor (BCrypt, SCrypt or PBKDF2). Very weak passwords can still be cracked then, in certain situations it helps if you encrypt the password-hashes with a server side key, as explained at the end of this tutorial.martinstoeckli

2 Answers

2
votes

You are right, it will not protect against awful passwords.

On a PC with eight AMD R9 290X graphics cards and hashcat, you can crack 797 Million SHA512 hashes per second.

That makes it very easy to check the password against a long dictionary of weak passwords.

If you use PBKDF2 with SHA512 and 20,000 iterations you can still manage 39000 Hashes per second, so weak passwords that appear on every password dictionary are still at risk.

It's best to force the users not to use passwords that are in the standard dictionaries. Brute forcing a single 7-letter alphanumeric, non-dictionary password would take 17 years on that machine.

Good luck with getting your users to use safe passwords. Dilbert reference:

1
votes

Given a hashed password database, passwords can be cracked out by (1) take a dictionary of all possible passwords (2) generate hash for each of possible passwords (3) tally each hash in given database against all the hashes you just generated.

So, cost-of-cracking-one-password = cost-of-generating-all-hashes + cost-of-matching-all-hashes

=> cost-of-cracking-1000-passwords = 1000 x cost-of-cracking-one-password or it seems so. But,

If there is NO salt, then cost-of-generating-all-hashes is constant and needs to be done only once. Then we can say that cost-of-cracking-the-whole-database is about-same as cost-of-cracking-one-password. Form this we see that in absence of salts, if a hacker gets hold of a password database, then the hacker will surely go to crack the whole database, not to target any single entry. In this way he will surely get at least a few hashes correct.

Salt is introduced to prevent this behavior. Now for a database with 1000 salted hashes, cost-of-cracking-1000-passwords = 1000 x cost-of-cracking-one-password. Note that even then cost-of-cracking-one-password is still same as previous cost-of-generating-all-hashes + cost-of-matching-all-hashes.

TLDR;

Salting does not protect individual passwords. Rather it is a deterrent against a hacker taking an initiative to crack the whole database.