SHA-512 w/ per User Salts is Not Enough(blog.mozilla.com)
blog.mozilla.com
SHA-512 w/ per User Salts is Not Enough
https://blog.mozilla.com/webappsec/2011/05/10/sha-512-w-per-user-salts-is-not-enough/
19 comments
The real kicker is that he tries to justify it by saying a sql injection attack would prevent the attacker from getting passwords. If you're seriously worried about sql injection, inventing a retarded password scheme seems like a secondary worry to revising your coding standards to require prepared statements.
Treating any part of a user password scheme as secret is doing it wrong. This is why bcrypt exists.
Treating any part of a user password scheme as secret is doing it wrong. This is why bcrypt exists.
Protecting one part of the system against code/development errors in other bits of the system seems like the sane thing to do. Maybe this guy is in control of the password scheme but not in control of the SQL stuff.
His entire argument hinges on this one sentence:
"Once the salt is known, it would be pretty trivial to dictionary a bunch of hashes in little or no time and get a pretty significant hit rate."
The author does not understand that salts primarily protect against rainbow tables (pre-computation attacks). He assumes the purpose is to increase brute force search complexity or somehow add additional secrecy, and is correct that it fails at both.
If you are already using user specific salts and a strong SHA hash, the next place you should be looking to add security is increasing the number of rounds (i.e. sha(sha(sha(hash+pass)))) or switching to bcrypt (which takes advantage of an expensive key setup phase in blowfish to make brute force searches very painful).
The author does not understand that salts primarily protect against rainbow tables (pre-computation attacks). He assumes the purpose is to increase brute force search complexity or somehow add additional secrecy, and is correct that it fails at both.
If you are already using user specific salts and a strong SHA hash, the next place you should be looking to add security is increasing the number of rounds (i.e. sha(sha(sha(hash+pass)))) or switching to bcrypt (which takes advantage of an expensive key setup phase in blowfish to make brute force searches very painful).
Rainbow tables don't really matter as much anymore when a consumer-grade GPU can calculate hundreds of millions of SHA/MD hashes per second. You're not really slowing an attacker down anymore.
Whenever this topic comes up, this link should be posted: http://codahale.com/how-to-safely-store-a-password/
Whenever this topic comes up, this link should be posted: http://codahale.com/how-to-safely-store-a-password/
You are off by an order of magnitude: a single GPU can do billions of hashes per second.
HD 6970 = 5.5 billion MD5/s http://golubev.com/gpuest.htm
HD 6970 = 5.5 billion MD5/s http://golubev.com/gpuest.htm
Wow, the iMac my parents just bought has a 6970m in it. Things have progressed on this front faster than expected.
Re-read the last sentence of my post.
Also, rainbow tables do matter. If you don't protect against them, they immediately become effective again. Your argument is "bump keys exist for locks, better take them off the doors!"
Also, rainbow tables do matter. If you don't protect against them, they immediately become effective again. Your argument is "bump keys exist for locks, better take them off the doors!"
I think the better point here is:
Bump keys exist for locks, lets not rely on them as a strong point for security.Rainbow tables are even more useless than I had thought. See: http://news.ycombinator.com/item?id=2546835
Just as a random question: Why are people using hash functions designed to be fast for large file digests/etc (ie. SHA) for password hashing?
Isn't this what scrypt/bcrypt/etc. are designed for?
Isn't this what scrypt/bcrypt/etc. are designed for?
It was much easier to teach "secure" password storage using hashed (because usually at this point you understood simple hashing but not enough about good cryptography).
Also when much of this started we didn't have hardware that could brute and entire database of hashes within hours.
Lastly, laziness.
Also when much of this started we didn't have hardware that could brute and entire database of hashes within hours.
Lastly, laziness.
This seems more complicated than it has to be.
hash(salt + nonce + password)
gets the same job done. If you don't trust your hash algorithm... pick a new one.
EDIT: It occurs to me that this whole notional improvement (the one from the article and my alternative) isn't as great as it might first seem: if an attacker gets the table of salt+password, and if the attacker knows the password to one account on the system, he can figure out what the nonce is by doing trial hashes using hash(nonce+salt_k+password_k), where salt_k and password_k are the known salts and passwords. In this way, he can figure out the nonce. Since you will very likely run into collisions when attempting to guess the nonce, you will have to have more than one known password, and you probably want to know something more about the nonce, e.g., its length, but fundamentally you're only increasing the difficulty of the attack by a small amount.
EDIT 2: thinking about it more, the right way around this is just to use a gigantic nonce. If your nonce is 1k, good luck brute forcing it. In this case, I'm fairly certain that my proposed alternative is just as sufficient as the original.
hash(salt + nonce + password)
gets the same job done. If you don't trust your hash algorithm... pick a new one.
EDIT: It occurs to me that this whole notional improvement (the one from the article and my alternative) isn't as great as it might first seem: if an attacker gets the table of salt+password, and if the attacker knows the password to one account on the system, he can figure out what the nonce is by doing trial hashes using hash(nonce+salt_k+password_k), where salt_k and password_k are the known salts and passwords. In this way, he can figure out the nonce. Since you will very likely run into collisions when attempting to guess the nonce, you will have to have more than one known password, and you probably want to know something more about the nonce, e.g., its length, but fundamentally you're only increasing the difficulty of the attack by a small amount.
EDIT 2: thinking about it more, the right way around this is just to use a gigantic nonce. If your nonce is 1k, good luck brute forcing it. In this case, I'm fairly certain that my proposed alternative is just as sufficient as the original.
Just a friendly reminder that string addition of salts in hash functions is a Bad Idea (tm), and that you should use HMACs instead.
Salt is bad for you: http://news.ycombinator.com/item?id=1209254
Also: http://codahale.com/how-to-safely-store-a-password/
Also: http://codahale.com/how-to-safely-store-a-password/
From your response it seems to me like you didn't read the article. The point of the article is to add a nonce to the standard salt+password scheme so that if you get the salt+password table, you still don't have enough info to brute force the password.
It's not that salt is bad so much as that it's insufficient. It's useful to keep straight up rainbow tables from working and to be sure that two users with the same password don't end up with the same value in the password table.
It's not that salt is bad so much as that it's insufficient. It's useful to keep straight up rainbow tables from working and to be sure that two users with the same password don't end up with the same value in the password table.
Do many platforms have a login-specific crypto call? That is, one tied to the user's system password? (Like Windows CryptProtectData.) That has the added benefit that if anyone steals the disk or resets the user's system password to login to their account, all such secrets are lost.
OS X has that; it's referred to as the "Keychain". Not sure if there's anything similar in any of the Linux DEs.
Both Gnome and KDE have similar applications/services:
http://live.gnome.org/GnomeKeyring
http://utils.kde.org/projects/kwalletmanager/
http://live.gnome.org/GnomeKeyring
http://utils.kde.org/projects/kwalletmanager/
And as for why this scheme is bad: your application has access to this "protected file" with secret shared key and so does attacker.