Proper way to use salt along with hashing

Question

During a discussion with a couple of other people, I read the argument that

sha512(salt + username + password) is bad,
sha512(username + password) is worse and
sha512(password) is plain idiotic.

While I partly agree, what's really the best security? Is there anything safer than using an user unique salt along with a slow hashing method such as SHA512? What's the real way to go? Argue on!

Please edit the title if you find it bad.

A unique salt per user, slow hashing algo (SHA512, bcrypt), and multiple hashing rounds (hash the hash the hash of the password and salt) should be adequate security. (Sidenote: LinkedIn got attacked. They were using unsalted SHA1 hashes :/. Goes without saying, most of the hashes have been cracked. ) — xbonez, Jun 07 '12 at 00:08
[SHA-512 is not slow.](http://thepasswordproject.com/oclhashcat_benchmarking) — Gumbo, Jun 07 '12 at 00:10
http://stackoverflow.com/questions/2043936/using-sha256-as-hashing-and-salting-with-users-id — walrii, Jun 07 '12 at 00:11

score 0 · Answer 1 · answered Jun 07 '12 at 00:13

When discussing the recent LinkedIn leak, somebody brought up this link about bcrypt. I think I agree... we should be using functions that increase the calculation time exponentially according to a factor. That's the only way we can beat people trying to use clusters or GPUs to do their hashing calculations.

score 0 · Answer 2 · answered Jun 07 '12 at 00:15

My understanding is, that repeated hashing (for computational cost) & a good random salt, should defeat all but seriously determined cryptographic attackers.

Hashing passwords in the database, and over the network, avoids plaintext being recoverable (and usable elsewhere) by a snooper or attacker who does get in.

Basically this is more or less the scheme, used by the Wordpress authentication:

var SALT = 64 random characters;
var NUM_HASHES = about 1000;    // can be randomized
var hashedResult = inputPassword;
for (int i = 0; i < NUM_HASHES; i++) {
  var dataToHash = SALT + hashedResult;
  hashedResult = secureHash( dataToHash);
}
//... can now store or send.

This use of a random salt, and looping hash, defeats any rainbow tables or single-level 'hash collision', 'hash weakness' attack. Only brute-forcing the complete keyspace, each key through 1000 iterations of the hash function, is believed to defeat it :)

But I wouldn't use an ad-hoc scheme like this. I recommend bcrypt, scrypt or PBKDF2. — CodesInChaos, Jun 07 '12 at 00:17

score 0 · Accepted Answer · answered Jun 08 '12 at 19:35

Generate random salt for each password.
Avoid MD5, and even SHA-1.
Use a slow hashing algorithm; SHA-256 seems to be a good choice for now.
Password storage is one of those rare occasions where there is some benefit to having your own (overall) algorithm. Consider an attacker with a rainbow table; if your password storage algorithm varies from the one used to generate their rainbow table enough to change the generated values, that rainbow table is of no use. The attacker would need to know your algorithm, then generate a new table. If you choose a slow hashing algorithm, generating a new table is very expensive.

By "overall" algorithm, I mean the complete definition of how you transform the plaintext password into the stored value. E.g. SHA-256("mypassword" + "[[" + 40-char-random-alphanum-salt + "]]"). If you change that to use angle brackets instead of square brackets, you've changed the rainbow table necessary to exploit your stored passwords. Note that I'm not advocating writing your own hash algorithm; you should still choose a cryptographically secure hash algorithm.

See this article by the author of MD5. He makes the two main points I repeated above: 1) if you use a fast hashing algorithm, you're missing the point, and 2) reuse of overall algorithms allows re-use of rainbow tables.

Proper way to use salt along with hashing

3 Answers3