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.

  • 3
    A single AMD graphics card can compute 200M guesses per second for single iterations SHA-512. Feb 22 '14 at 11:29
  • From a security standpoint, no, and of course it's not fine. SHA-512 is not meant to be cryptographically secure. There is a reason things like bcrypt exist.
    – SnakeDoc
    Feb 22 '14 at 23:35
  • 23
    @SnakeDoc: "SHA-512 is not meant to be cryptographically secure" - what do you mean, not meant to be cryptographically secure? It's a cryptographic hash function. Of course it was designed to be cryptographically secure. Whether the strength and cryptographic properties it was designed for are sufficient for this use case may be a different story. Feb 23 '14 at 3:16
  • 6
    @SnakeDoc It is cryptographically secure, it's just not designed to be a password-based KDF.
    – Thomas
    Feb 24 '14 at 3:21
  • @Aerovistae 184389 is the number of cracked passwords in the phpBB leak, see: thepasswordproject.com/leaked_password_lists_and_dictionaries 35406 is then number of entries in the d3ad0ne rule, see: github.com/bartavelle/rulesfinder/blob/master/benchrules/rules/…
    – astrograph
    Mar 24 '16 at 13:36

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.

  • 1
    He didn't actually ask about upgrading from SHA-1 to SHA-2, so I'm not sure what point you're making here. He seems to understand pbkdf2/bcrypt/etc should be used, he just asks whether sha512+salt is okay enough to pass the audit.
    – Luc
    Feb 22 '14 at 22:17
  • 12
    @Luc my point is that SHA-512+salt is not measurably more resistant to attack than SHA-1+salt. And if you intuitively understand that SHA-1+salt is insufficient (as many do), then that same understanding directly transfers to SHA-512, that the hash itself is largely irrelevant.
    – tylerl
    Feb 22 '14 at 22:41
  • 2
    @tylerl - for the current generation of GPU's, SHA-512 and the required 64-bit operations is, in fact, measurably slower. It's by a constant, true, but for SHA-512 vs. SHA-1 oclHashcat is ~6 times slower on a GTX 580, ~17 times slower on an HD 6990, and ~34 times slower on an R9 290X. This is for the attacker - the defender, almost certainly using a CPU, doesn't have nearly the slowdown (you'll have to take my word for it, but I show OpenSSL's SHA-512 is ~2 times slower than OpenSSL's SHA-1 on a Phenom II 1090 CPU). Feb 25 '14 at 0:50
  • I'm not sure I understand how iterating helps. If you run the algorithm 1000 times, that means a guess of whatever hash you had after 999 runs will be the correct guess after only 1 iteration. Why does the attacker have to do all the iterations?
    – KRyan
    Jul 21 '14 at 19:18
  • 2
    @KRyan, iterating helps because in any of the good iterated key derivation/password hashing techniques like SCrypt, BCrypt, and PBKDF2, iteration N's output is fed into iteration N+1 as one of the inputs. Some fairly readable code was written in T-SQL by user RZG in https://stackoverflow.com/q/7837547/1967612, or you can see the PBKDF2 spec at https://www.ietf.org/rfc/rfc2898.txt. Dec 29 '14 at 4:29

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.


  • 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.

  • 13
    Seems like a great answer but unfortunately not clear enough. A lot of the numbers seem to appear out of thin air. Could you make this more explicit? For example, what does "30 days of security" mean? What is keyspace exhaustion time? What is 184389, among other numbers? Mar 17 '16 at 6:17
  • Added glossary to answer the explanations, and listed that phpbb.txt is 184,389 actual passwords, and 35408 is the number of rules in the d3ad0ne ruleset (used for rules mangling on the very effective rule-based dictionary attacks. Jan 7 at 21:00

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.

  • 11
    I'm pretty sure Sony, Adobe, Kickstarter, Blue Ocean, Target, etc, all thought the cost of implementing good security was greater than what it would cost them in the event of a breach. They were wrong. And your advice about "it may not be worth doing" is just awful and helps build bad practices.
    – SnakeDoc
    Feb 22 '14 at 23:37
  • 13
    Sorry, but I'll have to disagree with you there. All businesses are commercial entities who are there to make money, not be "perfectly secure" (as if such a thing exists) and in those businesses security is a trade-off. If as a security person you tell the business to spend whatever is necessary to implement a control, you won't get much joy I'm afraid. As to Sony and the rest, do you have some citations for their risk analysis before their breaches? Feb 22 '14 at 23:50
  • 12
    I don't necessarily disagree with anything you've said, but if there's a significant amount of development time to switch from SHA-512 to bcrypt, you're doing something very, very wrong. ;-)
    – senfo
    Feb 23 '14 at 0:45
  • 6
    @senfo I'd agree but then when you run into an unsupported legacy system written by a third-party who have gone out of business, it's amazing how much simple fixes can cost... Feb 23 '14 at 12:03
  • 3
    I sympathise with @SnakeDoc. Sure, there is a legitimate trade-off between cost and security, but there's also a moral (and possibly legal) obligation to protect your clients' data. I wouldn't want to do business with a company that chooses to store my password in plain text because a breach is only going to cost $100. The question asks for something far less extreme; I don't know whether SHA-512 would qualify as intolerable bad practice, but I wouldn't be too quick to recommend it either. Feb 23 '14 at 23:53

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.

  • 2
    I just want to mention the cost of hashing is falling at an incredible rate due to BitCoin mining. Hashing power that was unheard of a couple years ago is now obsolete in the mining field. This hardware still has incredible power when used with applications like hashcat, so moving into the future I would be very wary of using SHA to hash passwords. Feb 22 '14 at 9:48
  • But isn't the ability to brute force dependent on the underlying authentication system? If delays are enforced on failed authentication or the number of attempts are limited then how do you brute unless it is perhaps a distributed attack (but that could be slowed or even blocked) or the system itself has already been compromised?
    – MrWhite
    Feb 22 '14 at 16:09
  • 14
    @w3d You are thinking about an online bruteforce. Hashing is really only relevant when talking about offline bruteforce attacks after your database has been dumped.
    – user10211
    Feb 22 '14 at 16:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.