3 ms·

Yep. Don't store passwords using (non-password) fast hashes like MD5 or SHA-256. Use bcrypt: http://codahale.com/how-to-safely-store-a-password/ http://codahale

Yep. Don't store passwords using (non-password) fast hashes like MD5 or SHA-256. Use bcrypt: http://codahale.com/how-to-safely-store-a-password/ http://codahale.com/how-to-safely-store-a-password/

Joakal 15y ago
His recommendation of not using salts is very misleading and should not be quoted due to poor advice as Bcrypt is also useless against dictionary and brute force attacks. The aim of password storage security is to prevent pre-computed hashing reasonably enough. No amount of password hashing even if it takes 1000 years to hash a password if your users use '12345678' as a password. Salting protects against pre-computed hashes (rainbow tables [0]). Otherwise I can pre-compute many bcrypt hashes and then quickly look up the password. [0] https://secure.wikimedia.org/wikipedia/en/wiki/Rainbow_tables https://secure.wikimedia.org/wikipedia/en/wiki/Rainbow_table...
- tptacek 15y ago
  No; you're incorrect. All secure password storage schemes are randomized. If you insist on using the word "salt", then just know that bcrypt, scrypt, and the PBKDFs build the salt in. You cannot "pre-compute many bcrypt hashes and quickly look up passwords". So: if you're using a scheme that requires you to think about salts, you are virtually certain to be using an insecure storage scheme. And, dictionary and brute force attacks are the entire problem bcrypt is designed to address. Go back to that article that you didn't really read, follow the first Usenix link, and read the Usenix paper it cites.
  - Joakal 15y ago
    I'm concerned that you advocate ignorance of 'salt'. Some functions[0][1] seem to optionally allow the use of salt, are you saying that users should just use passwords as input with bcrypt hashing? In the article, it does not suggest only bcrypt as well [2]. [0] http://www.mindrot.org/projects/py-bcrypt/ http://www.mindrot.org/projects/py-bcrypt/ [1] http://au.php.net/crypt http://au.php.net/crypt [2] http://www.usenix.org/events/usenix99/provos/provos_html/node16.html#SECTION00070000000000000000 http://www.usenix.org/events/usenix99/provos/provos_html/nod...
    - tptacek 15y ago
      Bcrypt uses a 128 bit salt. The code I provided above didn't show it, because the library simply generated it for me. The bcrypt libraries that require users to explicitly provide a salt are themselves doing their users a (slight) disservice, by making it seem as if there was a reasonable option for salt generation other than simply using a CSPRNG.
      - djmdjm 15y ago
        > The code I provided above didn't show it, because the library simply generated it for me. ... and this is another reason why people should use one of the bcrypt() implementations for their language* - the API makes doing the wrong thing difficult or impossible. * disclosure: I ported/wrote a couple of them

Yep. Don't store passwords using (non-password) fast hashes like MD5 or SHA-256. Use bcrypt: http://codahale.com/how-to-safely-store-a-password/ http://codahale.com/how-to-safely-store-a-password/

Joakal 15y ago

His recommendation of not using salts is very misleading and should not be quoted due to poor advice as Bcrypt is also useless against dictionary and brute force attacks. The aim of password storage security is to prevent pre-computed hashing reasonably enough. No amount of password hashing even if it takes 1000 years to hash a password if your users use '12345678' as a password. Salting protects against pre-computed hashes (rainbow tables [0]). Otherwise I can pre-compute many bcrypt hashes and then quickly look up the password. [0] https://secure.wikimedia.org/wikipedia/en/wiki/Rainbow_tables https://secure.wikimedia.org/wikipedia/en/wiki/Rainbow_table...

tptacek 15y ago
No; you're incorrect. All secure password storage schemes are randomized. If you insist on using the word "salt", then just know that bcrypt, scrypt, and the PBKDFs build the salt in. You cannot "pre-compute many bcrypt hashes and quickly look up passwords". So: if you're using a scheme that requires you to think about salts, you are virtually certain to be using an insecure storage scheme. And, dictionary and brute force attacks are the entire problem bcrypt is designed to address. Go back to that article that you didn't really read, follow the first Usenix link, and read the Usenix paper it cites.
- Joakal 15y ago
  I'm concerned that you advocate ignorance of 'salt'. Some functions[0][1] seem to optionally allow the use of salt, are you saying that users should just use passwords as input with bcrypt hashing? In the article, it does not suggest only bcrypt as well [2]. [0] http://www.mindrot.org/projects/py-bcrypt/ http://www.mindrot.org/projects/py-bcrypt/ [1] http://au.php.net/crypt http://au.php.net/crypt [2] http://www.usenix.org/events/usenix99/provos/provos_html/node16.html#SECTION00070000000000000000 http://www.usenix.org/events/usenix99/provos/provos_html/nod...
  - tptacek 15y ago
    Bcrypt uses a 128 bit salt. The code I provided above didn't show it, because the library simply generated it for me. The bcrypt libraries that require users to explicitly provide a salt are themselves doing their users a (slight) disservice, by making it seem as if there was a reasonable option for salt generation other than simply using a CSPRNG.
    - djmdjm 15y ago
      > The code I provided above didn't show it, because the library simply generated it for me. ... and this is another reason why people should use one of the bcrypt() implementations for their language* - the API makes doing the wrong thing difficult or impossible. * disclosure: I ported/wrote a couple of them