3 ms·

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

• freditup 14y ago
  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.
• ohgodthecat 14y ago
  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 14y ago
    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).
• huxley 14y ago
  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-password-storage/ 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.
• dllthomas 14y ago
  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.
• dutchbrit 14y ago
  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.