Is using SHA-512 for storing passwords tolerable?

Question

I know that the best options to use for storing passwords are bcrypt/PBKDF2/scrypt.

However, suppose you have to audit a system and it uses SHA-512 with salt. Is that "fine"? Or it is a vulnerability that must be addressed, even thought your site is a discussion forum?

Of course, if it is weak, it must be addressed, because users passwords may be used on other sites as well. The question is - is it too weak not to tolerate it as a possibility.

Answer 1

No, you're solving the wrong problem.

Moving from SHA-1 or SHA-256 to SHA-512 doesn't make cracking the hash significantly harder. Hashes generally aren't reversed by means of some mathematical property of the algorithm, so advancing the algorithm doesn't changing the security very much.

Instead, hashes are brute-forced using a "guess and check" technique. You guess a password, compute the hash, and then check to see if you guessed correctly. And repeat, and repeat, and repeat until you finally get it.

So the way to slow down the attacker is to slow down the hashing process. If it takes longer to check each single password, then the attacker can't guess as many of them. And in this case, SHA-512 isn't appreciably slower than SHA-256 or SHA-1 or MD5. So you're not really adding any security.

Instead, the common thread between techniques like bcrypt, PBKDF2, and scrypt, is that they all run the hashing function over and over and over, thousands of times for just one single password guess. So say a site uses PBKDF2 at 10,000 iterations: this means that the attacker has to expend as much time and resources on a single guess as he otherwise would have to on an entire dictionary of 10,000 passwords. By slowing the attacker, you limit the number of passwords he ultimately can guess, and therefore decrease the likelihood of him eventually guessing correctly.

Many installations tailor their configuration to fit existing hardware. So for example, LUKS uses a minimum of 1000 iterations, or however many it takes to consume 1/8th of a second, whichever is longer.

Answer 2

However, suppose you have to audit a system and it uses SHA-512 with salt. Is that "fine"? Or it is a vulnerability that must be addressed, even thought your site is a discussion forum?

Assuming it's a per-username long cryptographically random salt, and your audit doesn't have to follow any particular regulatory or legal rules, then I would suggest a little math.

It's a discussion forum, so I assume users never have to change their passwords. Thus, the basic questions are:

• For how long should a "normal" password be secure, on average?
• What is the assumed keyspace of a "normal" password?
• At what rate do you expect an attacker to be able to try passwords in an offline attack?

We have the basic equation:

• Average time of security * 2 = Keyspace exhaustion time

We use the following useful equations:

• Keyspace exhaustion time * test rate = minimum keyspace for "normal" passwords
• Minimum keyspace for "normal" passwords / keyspace exhaustion time = maximum attack rate
• minimum keyspace for "normal" passwords / test rate = keyspace exhaustion time

Thus, if we take this example:

• 30 days of security for a "normal" password, on average
• "Normal" passwords are the phpbb leak wordlist (which contains 184,389 actually used passwords) * the "d3ad0ne" ruleset (which contains 35,408 rules to take one string and turn it into another for passwords, such as add a 1 at the end, capitalize every letter, capitalize the first letter and add a 1 at the end, and so on).

We have the result:

• 30 * 2 * 24 * 3600 = 5184000 seconds keyspace exhaustion time
• 184389 * 35408 = 6528845712 possible passwords (keyspace)
• 6528845712 / 5184000 = 1259 tries/second is the maximum attack rate.
• This is blatantly insufficient, as OclHashcat lists a rate of 797 million tries/sec for a single PC (8x AMD R9 290Xstock core clock).

If we go the other way, we have:

• "Normal" passwords are the phpbb leak wordlist * the "d3ad0ne" ruleset
• Test rate is 797 million tries/sec

Thus, we get:

• 184389 * 35408 = 6528845712 possible passwords (keyspace)
• 797000000 tries/sec
• 6528845712 / 797000000 = 8 seconds.
• Obviously, with a single modern computer and these keyspace assumptions, your "normal" users would each be cracked in 8 seconds.

Note that if you had 1,000 users, that would be:

• 1000 * 8 = 8000 seconds, or 8000/3600 = 2.2 hours on average to crack all the "normal" passwords out of the 1000.

Now, if you assume your users select cryptographically random 8 character passwords, using upper case, lower case, and numbers (good luck with that!):

• 62^8 = 218340105584896 keyspace
• 797000000 tries/sec
• 218340105584896 / 797000000 = 273952 seconds
• 273952 / 3600 = 76 hours. Still generally insufficient, but clearly if you can bump up the minimum length just a little (and keep the perfect randomness and character set), then you'd be ok.

First pick the numbers that make sense, then do the math. The answer will be obvious after that. Nothing you can do to hash "12345" will ever make it secure - you have to forbid blatantly poor passwords outright. Even a single round of SHA-512 will fully secure a 128 character cryptographically random password. Most users choose things far closer to 12345, though.

GLOSSARY

• Days of security: How many days is it expected to take to crack a given password, on average- in this example, with an offline attack and a single modern computer. Ideally you'd want this to be quite significantly high, even for moderately poor passwords.

• Keyspace: the total number of possible keys (and a key is essentially whatever a password is stored as - for instance, SHA-512(password) or a PBKDF2 value. For this example, we can assume keyspace = total # of possible passwords. So, if passwords are only 2 digits and numeric, the keyspace is 20. If passwords are only lower case letters and 1 character long, the keyspace is 26. If passwords are lowercase + numbers and are 3 characters long, the keyspace is (26+10)^3.

• Keyspace exhaustion time: The amount of time it would take to test every single key in the keyspace, i.e. how long an exhaustive attack would take. If you have 2 keys in the keyspace, and they take 1 second each to test/crack, in 2 seconds you've exhausted the keyspace. If there are 3600 keys in the keyspace, and they take 1 second to test/crack, keyspace exhaustion time is 1 hour. The average time to crack for any one key is half the keyspace exhaustion time.

Answer 3

I'm afraid it's not possible to answer whether this is "fine" or not with regards to an audit, without the context of the organisation that is performing the audit. A risk level that is fine for one company may well be entirely unacceptable for another.

In terms of the technical specifications of your question. Assuming that you're using SHA-512 with per-user salt, this may be considered fine depending on the threats you face and the impact of a breach. It's definitely better than unsalted MD5 but obviously not as good as bcrypt/PBKDF2/scrypt.

It would be relatively resistant to things like rainbow table attacks but not resistant (as @terrychia says) to a dedicated attacker with hardware assisted cracking facilities and time to spend.

So whether it's fine for you could depend on whether you expect that grade of attacker to target the site and what level of impact a breach would have.

If, for example, a breach would cost you $1 million in direct/indirect loss then it would seem a bad idea to rely on an setup which is acknowledged to be less than ideal.

However if a breach would cost you $100 then it's likely that the developer time needed to implement the fix wouldn't be worth it.

Answer 4

No, it is not fine.

Plain SHA512 can be bruteforced at a pretty fast rates using things like GPUs/FPGAs/ASICs. If there is at all a possibility of fixing it, definitely change it to use something like bcrypt, scrypt or pbkdf2.