Is using SHA-512 for storing passwords tolerable?

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

    A single AMD graphics card can compute 200M guesses per second for single iterations SHA-512.

    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: "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.

    @SnakeDoc It is cryptographically secure, it's just not designed to be a password-based KDF.

    @Aerovistae 184389 is the number of cracked passwords in the phpBB leak, see: 35406 is then number of entries in the d3ad0ne rule, see:

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

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

    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, 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, or you can see the PBKDF2 spec at

  • 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 * the "d3ad0ne" ruleset

    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.

    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?

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

    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.

    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?

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

    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.

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

    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.

    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?

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

License under CC-BY-SA with attribution

Content dated before 7/24/2021 11:53 AM

Tags used