Ask HN: Would salted passwords have helped LinkedIn? Should we still use them? | Hacker News Reader

Ask HN: Would salted passwords have helped LinkedIn? Should we still use them?

8 pointscbhl6 comments

A roommate asked me this question, and I was curious as to whether there's some insight that I'm lacking.

His arguments:

1) If the salts are stored in the database with the hashes, wouldn't it still be possible to brute-force/attack the salt+hash combination?

2) In the context of [0], don't advances in parallel computing (particularly wrt. "general-purpose" computing on GPUs) make it relatively easy to generate a rainbow table for each salt encountered (compared to, say, two, or even seven years ago)?

[0] http://stackoverflow.com/questions/5252943/why-we-use-the-salt-to-secure-our-passwords

View on HN

Well, that's why you should use something like bcrypt and not a fast hashing algorithm. When you intentionally use a slow algorithm, it's much harder and slower to generate these tables.

With no salt or a common salt, you can generate the hashes for every common password once. If you have a long salt for each password, you have to generate the hashes for every common password for every password, which would take years longer to do. If your goal is to hack one individual account, the salt won't help. But to hack accounts in general, it will help.

I'm not an expert, but that's my understanding of it. Anyone please feel free to correct me if I'm wrong.

I would go with SHA512, and yes, still salt. It makes the user have to brute force instead of looking up the password in a database.

This is how I understand it. Bcrypt uses Blowfish. Blowfish is not a hashing algorithm but an encryption algorithm. This meaning, you can encrypt something, and then, decrypt it back to plain text.

SHA512 on the other hand is a hashing algorithm which should mean that it's impossible to revert. At the end of the day, everything is crack able through brute force. Just try and make it harder for the hacker. You could also add additional salts to a password, defined in code. Or add the salt after the 2nd character of the users inputted password for example. This however is only handy if a hacker hasnt gained access to your source code but only to your database. Additionally, encrypting your sourcecode where the algorithm is implemented adds an additional security layer. There are tons of ways to make it crazy hard to crack a password.

Mozilla is using an interesting approach to password security with their web apps (coded in Django):

http://blog.mozilla.org/webdev/2012/06/08/lets-talk-about-pa...

tl;dr Keep secret key on app server (ie on different server than database), hash it and password with HMAC-SHA256, then hash that with bcrypt for storage in database. Secret key is in a dictionary which allows you to can change the key periodically and deprecate old or questionable keys.

A salt means you have to brute force one password at a time. This is way slower than brute forcing all passwords at once, and you can't do it in advance (like with a rainbow table). Of course, bad passwords will still be crackable, but it slows it way, way down on any given amount of hardware. So yes, it would have helped.

I believe that the salt is able to prevent rainbow tables because of storage capacity, as rainbow tables are quite large.

That makes the pre-generation of these rainbow tables quite impossible, especially with how long many salts are.

Now of course you can start generation when you have the salt but that doesn't really make any difference between just cracking the passwords as you go.

Whether or not it would have helped LinkedIN I can't really say but it probably would have been a bit better as people woulnd't have been able to compare the list to known passwords as quickly (but probably not much of a difference there if they knew the salt).

This is correct. Salt just defeats rainbow tables. They could still be pre-generated for high-value usernames, though.

Some say that this is most useful in giving the company a more sizeable window in which to react (e.g. force password changes).

Reply on news.ycombinator.com