views:

502

answers:

6

I understand that salts make the same password hash to different values. However, salts are usually stored in the database with the password. So let's say I am attacker, here is how I might use a dictionary attack against a salt (note in this example i don't write out 128 bit hashes or salts for the sake of brevity):

user_pw = 'blowfish'

Given:
email = '[email protected]'
hash = '1234567890'
salt = '0987654321'

function attack(){
  for each(word in dictionary)
    md5( word * salt ) == hash ? cracked_one(email, word)
}

I understand this prevents hackers from using rainbow tables...but doesn't seem to prevent dictionary attacks. I guess you could add something else to the hash algorithm, but with security we must assume that the method of attack is known.

So it seems that salting prevents hackers from figuring out which passwords are likely to be dictionary passwords (ones that multiple users have) and prevents rainbow attacks...but does not prevent dictionary attacks.

Is this a correct analysis? Any suggestions for better security?

Thanks!

+1  A: 

That's correct. If someone got the password material, a dictionary attack would be effective.

To guard against this:

  • Make sure your passwords aren't subject to dictionary attacks.
  • Make sure your password file (/etc/shadow) is readable only by root.
Jared Oberhaus
This is perhaps an obvious questions in hindsight, but is there an option to reject passwords that are found in a dictionary? I'm not asking specifically about Unix variants, either.
Steven Sudit
@Steven Sudit: you can use cracklib for this purpose
hayalci
Sure, but is this integrated into the password change system?
Steven Sudit
If pam_cracklib.so included in the PAM stack, it is integrated.
hayalci
A: 

Your logic is sound, but in reality, with enough computing power and time, there is no protection against dictionary/brute-force attacks.

byte
Perhaps with enough power and time, there is no protection against brute force attacks. However, using a password that's not in any dictionary is sufficient to protect you from any dictionary attack.
Steven Sudit
good point, but training users to select secure passwords is an effort in itself
farinspace
+9  A: 

Salt doesn't prevent dictionary attacks, just precalculated dictionary attacks. In particular, it protects against rainbow tables (http://en.wikipedia.org/wiki/Rainbow_table) and also ensures that cracking one user's password doesn't automatically let you crack any user who shares that password.

The article I linked to mentions some ways to improve upon salting, incudling key strengthening (http://en.wikipedia.org/wiki/Key_strengthening).

Steven Sudit
it seems like the big difference is that by using a salt, the attacker would basically have to compute a new dictionary or rainbow table for each salt or user. do you know how long it takes to compute a rainbow table maybe on 1 million words? (not looking for an exact answer here)
Tony
Not personally, but http://project-rainbowcrack.com/table.htm says you don't need to make your own: you can download theirs. Worse, the crackers are taking advantage of the NVidia Cuda GPU to accelerate their efforts.These rainbow tables are huge, even by modern standards, so multiplying them by as little as 4G (32 bits) is enough to make it entirely infeasible to even STORE every possible rainbow table, forgetting the cost of generation.
Steven Sudit
+1  A: 

Without salt, the attacker can generate hashes for every word in his dictionnary then run the new dictionnary against your passwords list

With salt, each password is hashed with a random string so even with the prior hashed dictionnary knowledge, he still have to re-create a new hashed dictionnary containing the salt for every different salt in your database.

Just think of dictionnaries tables as a subset (small portion) of the rainbow tables. While rainbow tables can contain billions of entries, dictionnaries contain "known words", so maybe a few million entries at most.

The reason why rainbow tables fail against salt is because the re-creation process would be "billions of entries" of recalculation while dictionnary attacks are still "few millions of entries". The salt just blocks precomputed values

Eric
I'm not sure that's exactly correct. Brute force implies a sequential or random search through the possible password space. With salt, the attacker can still apply the salt and hash to a dictionary, but they have to pick a single salt value to do it for and they're not going to have that value arbitrarily in advance, so they'll have to calculate it on the fly.
Steven Sudit
@steven you are right, I corrected the misunderstanding
Eric
+4  A: 

Nothing keeps an attacker from just guessing the password.

Salts just make it harder by forcing an attacker to hash the dictionary on a per-user (effectively, per-salt) basis.

To improve security, a tunable hash function is your best bet. Crank the time-per-hash up, making dictionary attacks impractical on whatever hardware your attacker is likely to have available.

Basically, read this.

Kevin Montrose
The tunable hash approach sounds just like key strengthening. Any hash can be tuned this way by running it over and over again.
Steven Sudit
Yep, it's key strengthening and a related technique. Good article, though, especially the part about SRP. Thanks.
Steven Sudit
A: 

I'd suggest reading this

zebrabox
This happens to be the same article that Kevin Montrose linked to earlier.
Steven Sudit