Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>SHA512 is not a terrible choice. But it won't be long before it is cracked for most lengths of passwords. Take <a href="http://www.codinghorror.com/blog/2012/04/speed-hashing.html" rel="noreferrer">Jeff's Advice</a>. Use <a href="http://en.wikipedia.org/wiki/Bcrypt" rel="noreferrer">bcrypt</a> or <a href="http://en.wikipedia.org/wiki/Pbkdf2" rel="noreferrer">PBKDF2</a>. They are resistant to EC2 or other parallel processing techniques. Probably not immune, but resistant.</p> <p>The reason a better hash isn't better in this case is <code>ABC</code> in MD5 becomes one value and <code>ABC</code> in SHA512 becomes one value. Calculating all the 3 letter passwords is <a href="http://www.cryptopp.com/benchmarks.html" rel="noreferrer">actually easier for SHA512 than it was for MD5</a>. The key is to be hard to do. That means a slow hash, one that uses a lot of RAM, and/or one that can't be easily done on EC2.</p> <p>The best choice is to NOT use passwords alone anymore at all. Decide if login is really needed for your site, and if it is, try to use a 3rd party provider first. If that's not an option consider a password + token from RSA. Only use a password alone if you have no other viable options.</p> <p>When hashing a password the key is to <strong>hash(password + salt)</strong> and the salt needs to be unique per user, and should also be difficult or impossible to guess. Using the Username meets the first criteria and is better than no salt or the same salt for each user, <strong>but a unique random salt for each user is a better choice</strong>. Ideally in a separate database, if not location, with its own credentials. It should also be keyed not on the username, but on the user_id or even a hash of the user_id. You want that database to be SQL injection proof. Accepting no input from the user that isn't hashed is a good way to do that. And you would be wise to let the query itself do the hashing. Slow? Yes, and that's ALSO a good thing.</p> <p>The salt itself should contain all the hard to predict data it can get. Username + User Id + Timestamp + garbage from dev/urandom + the latest tweet with the word taco in it. Longer the better. SHA512 is a good choice of hash here.</p> <p>Summary: hash = bcrypt(password + salt), salt = sha512(username + user_id + timestamp + microtimestamp + dev/urandom bits + other noise).</p> <p>If you are still worried after all of that. Feel free to SHA512 the bcrypted password. You'll gain the strength of SHA512, which when cracked only reveals a much harder to brute force bcrypted hash.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload