

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

A roommate asked me this question, and I was curious as to whether there's some insight that I'm lacking.<p>His arguments:<p>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?<p>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)?<p>[0] http://stackoverflow.com/questions/5252943/why-we-use-the-salt-to-secure-our-passwords
======
freditup
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.

------
dutchbrit
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.

------
huxley
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...](http://blog.mozilla.org/webdev/2012/06/08/lets-talk-about-password-
storage/)

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.

------
dllthomas
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.

------
ohgodthecat
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).

~~~
sejje
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).

