Best practice for hashing passwords - SHA256 or SHA512?

84,853

Solution 1

Switching to SHA512 will hardly make your website more secure. You should not write your own password hashing function. Instead, use an existing implementation.

SHA256 and SHA512 are message digests, they were never meant to be password-hashing (or key-derivation) functions. (Although a message digest could be used a building block for a KDF, such as in PBKDF2 with HMAC-SHA256.)

A password-hashing function should defend against dictionary attacks and rainbow tables. In order to defend against dictionary attacks, a password hashing scheme must include a work factor to make it as slow as is workable.

Currently, the best choice is probably Argon2. This family of password hashing functions won the Password Hashing Competition in 2015.

If Argon2 is not available, the only other standardized password-hashing or key-derivation function is PBKDF2, which is an oldish NIST standard. Other choices, if using a standard is not required, include bcrypt and scrypt.

Wikipedia has pages for these functions:

EDIT: NIST does not recommend using message digests such as SHA2 or SHA3 directly to hash passwords! Here is what NIST recommends:

Memorized secrets SHALL be salted and hashed using a suitable one-way key derivation function. Key derivation functions take a password, a salt, and a cost factor as inputs then generate a password hash. Their purpose is to make each password guessing trial by an attacker who has obtained a password hash file expensive and therefore the cost of a guessing attack high or prohibitive. Examples of suitable key derivation functions include Password-based Key Derivation Function 2 (PBKDF2) [SP 800-132] and Balloon [BALLOON].

Solution 2

SHA256 is still NIST Approved, but it would be good to change to SHA512, or bcrypt, if you can.

The list of NIST approved hash functions, at time of writing, is: SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256, and SHA3-224, SHA3-256, SHA3-384, and SHA3-512, SHAKE128 and SHAKE256.

See https://csrc.nist.gov/projects/hash-functions

Depending on what operating system you are running, you probably don't have access to the SHA3 or SHAKE hash functions.

Many people prefer bcrypt to SHA512, but bcrypt is also only available on some operating systems.

SHA512 will be available on your system, or if not, you probably have such an old system that choice of hashing algorithm is the least of your problems.

One reason commonly given for preferring bcrypt is that bcrypt is tuneable - you can increase the number of rounds (work factor) to increase the time it takes to crack bcrypt hashes.

But SHA256 and SHA512 are also tuneable. While the default is 5000 rounds, you can specify more if you wish. 500000 takes my current pc about 0.45 seconds to calculate, which feels tolerable.

e.g.:

password    required    pam_unix.so sha512 shadow rounds=500000 ...

The reason to change from SHA256 to SHA512 is that SHA256 needs a lot more rounds to be as secure as SHA512, so while it's not insecure, it's less secure.

See, for example: https://medium.com/@davidtstrauss/stop-using-sha-256-6adbb55c608

Crypto changes quickly, so any answer you get might be proved wrong tomorrow, but current state of the art is that while bcrypt is possibly better than SHA512, SHA512 is fine.

If SHA512 is what you have available 'out of the box', use it (not SHA256), and don't worry about bcrypt or any of the SHA3 family until they become standard for your distribution.


As an aside, the current top rated answer has a number of claims that are either wrong or misleading.

"Switching to SHA512 will hardly make your website more secure."

This is misleading. Switching to SHA512 will make your site slightly more secure. SHA256 isn't as good as SHA512, but it isn't dreadful either. There's nothing that is clearly better than SHA512 that is likely to be available on your system yet. Bcrypt might be better, but this isn't clear, and bcrypt isn't available on a lot of systems. The SHA3 family is probably better, but it isn't widely available either.

"SHA256 and SHA512 were never meant to be password-hashing"

This is wrong. Both SHA256 and SHA512 are approved NIST hash algorithms.

"to defend against dictionary attacks, a password hashing scheme must include a work factor to make it as slow as is workable."

This is wrong. A high work factor will protect against brute force hash cracking, but not against a dictionary attack. There is no work factor that is low enough to be usable but high enough to protect against a dictionary attack. If your password is a dictionary word, it will fall to a dictionary attack. The protection against a dictionary attack to not use passwords that can be found in dictionaries.

On my current PC, the limit on rounds seems to be 10 million, which produces a delay of 8.74 seconds for each password entered. That's long enough to be extremely painful, longer than you'd want to use. It's long enough to prevent a brute force attack - but a determined adversary with a good cracking rig and a bit of patience could still iterate through a dictionary if they wanted to.

"A password-hashing function should defend against ... rainbow tables"

This is, at best, misleading. The defence against rainbow tables is to make sure that each password has their own 'salt'. That's pretty much standard practice these days, and it happens before the hash function is called. (Salting means adding a random string to the password before hashing it. The salt is stored with the password, so it's not a secret, but it does mean that even if a user picks a well-known password, the attacker can't just recognise that {this hash} belongs to {that password}, they still need to crack the hash.)

"Currently, the best choice is probably Argon2. This family of password hashing functions won the Password Hashing Competition in 2015."

This is unclear. Any 'new' cryptographic function can have unobvious ways of being broken, which is why most people prefer functions that have been widely used. Besides which, Argon2 is probably not available to you.

"Other choices, if using a standard is not required, include bcrypt and scrypt."

This is unclear. At one point, scrypt was seen as a better bcrypt. However, for various reasons, sentiment has moved away from scrypt towards bcrypt. See, for example: https://blog.ircmaxell.com/2014/03/why-i-dont-recommend-scrypt.html

To repeat, at this point in time, SHA512 appears to be a good choice and so does bcrypt.

SHA512 is NIST approved and bcrypt is not.

SHA512 will almost certainly be available on your system. Bcrypt may or may not be.

If both are on your system, I'd probably recommend bcrypt, but it's a close call. Either is fine.

Solution 3

SHA512 may be significantly faster when calculated on most 64-bit processors as SHA256ses 32-bit math, an operation that is often slightly slower.

Solution 4

This has already been answered reasonably well, if you ask me: https://stackoverflow.com/questions/3897434/password-security-sha1-sha256-or-sha512

Jeff had an interesting post on hashing, too: http://www.codinghorror.com/blog/2012/04/speed-hashing.html

Note that SHA512 is a lot slower to compute than SHA256. In the context of secure hashing, this is an asset. Slower to compute hashes mean it takes more compute time to crack, so if you can afford the compute cost SHA512 will be more secure for this reason.

Share:
84,853
econner
Author by

econner

Updated on July 09, 2022

Comments

  • econner
    econner almost 2 years

    I am currently using SHA256 with a salt to hash my passwords. Is it better to continue using SHA256 or should I change to SHA512?

    • Monarchis
      Monarchis over 4 years
      Due to the higher collision propability of passwords with sha-256 the use of sha-512 is more recommended. That means in fact: In case of a rainbowtable-attack the passwords hashed with sha-256 algorithm are easier to crack.
    • cat_in_hat
      cat_in_hat over 4 years
      @Monarchis wouldn't that be solved by adding a salt?
  • martinstoeckli
    martinstoeckli almost 11 years
    None of the proposed hash algorithms are appropriate to hash password, you should use a slow key-derivation function like BCrypt of PBKDF2 instead.
  • Nikos C.
    Nikos C. about 9 years
    According to the crackstation link you posted, SHA256 is a cryptographic hash function and is suitable for passwords due to low collision probability.
  • Erwan Legrand
    Erwan Legrand about 9 years
    @NikosC. I had a look at the page. At best, it is poorly worded. (Although it states at some point that using a salted message digest to hash passwords will fall to dictionary attacks.) I should not have linked to it. Dictionary attacks have been known for a long time. A paper by Robert Morris and Ken Thompson, "Password Security: A Case History.", dated 1978-04-03 discusses it and explains that a work factor was included in the password hashing function for Unix. A password scheme without a work factor is weaker than what was used in the 1970's!
  • Erwan Legrand
    Erwan Legrand about 9 years
    On my box, SHA512 is only 20% slower than SHA256. I've checked with "openssl speed sha256" vs ""openssl speed sha512".
  • Joe B.
    Joe B. over 8 years
    The SO link was removed "for reasons of moderation."
  • michael
    michael over 8 years
    Since the linked-to SO answer was deleted, here are some other relevant SO answers: stackoverflow.com/questions/1592608/… and stackoverflow.com/questions/20186354/…
  • prasun
    prasun over 8 years
    in certain cases as mentioned in this discussion SHA-512 may be faster than SHA-256 crypto.stackexchange.com/questions/26336/…
  • My1
    My1 over 8 years
    also since these operations are fast they can be bruteforced relatively leasy. I use bcrypt with a cost of 16 (roughly 5 sec on my dev PC and hoster)
  • Erwan Legrand
    Erwan Legrand over 7 years
    Folks have been down-voting this answer lately without commenting. If you think this answer is a bad one, please explain why.
  • Top Sekret
    Top Sekret about 7 years
    32-bit math is not slower ;p It's usually the same speed (if one had a super duper clock, 32-bit would be even unspottably faster)
  • LinuxSecurityFreak
    LinuxSecurityFreak over 6 years
    I did some tests confirming SHA-512 is 50% faster on 64-bit CPU: crypto.stackexchange.com/a/52646/42045
  • Ben Aveling
    Ben Aveling over 4 years
    There's too much wrong with this answer to fit in a comment. See my answer below. Sorry.
  • Erwan Legrand
    Erwan Legrand over 4 years
    You are confusing SHA-256 and SHA-512 with the Linux PAM SHA-crypt. SHA-256 and SHA512 are Message Digest algorithms standardized by NIST while SHA-crypt is a password hashing scheme invented by a bunch of Linux developers and described here: akkadia.org/drepper/SHA-crypt.txt. These guys did not know about PBKDF2 or they would have used PBKDF2 with HMAC-SHA-256 and HMAC-SHA-512 instead of reinventing the wheel. SHA-256 and SHA-512 are not password hashing schemes. They are not tunable. Using plain SHA-256 or SHA-512 to hash passwords is a recipe for disaster!
  • Erwan Legrand
    Erwan Legrand over 4 years
    -1 as you appear to think you know better than the cryptographers who judged Argon2 to be the best password hashing scheme available. The work done by Password Hashing Competition is probably the best source of information available on password hashing.
  • Erwan Legrand
    Erwan Legrand over 4 years
    I had a look at both of the links you provided. Did you even notice that both authors recommend using Argon2?
  • Ben Aveling
    Ben Aveling over 4 years
    Argon2: promising but not widely used. Probably not available on your box. Has not had as many eyeball-years as other choices. Use it if you have a reason to use it, but don't feel bad if you can't use it.
  • Ben Aveling
    Ben Aveling over 4 years
    SHA-256 / SHA-512 vs PAM SHA-crypt: PAM SHA-crypt is an implementation of SHA-256/SHA-512. Yes, there's a difference between an implementation of an algorithm and the algorithm, but if anyone is asking Stack Overflow 'what algorithm should I use', they're really asking 'out of the algorithms for which I have an implementation available to me, which should I use'. They are not not asking 'which algorithm should I implement'.
  • Ben Aveling
    Ben Aveling over 4 years
    SHA-256 and SHA-512 tunable: I suggest you find the following line (or equivalent) on your nearest unix host: "password required pam_unix.so sha512 shadow rounds=5000 ...". Change your password. Increase the 5000 to 5000000 then and then change your password again. Tell me if you notice a difference.
  • xuiqzy
    xuiqzy over 4 years
    Please add the relevant passages from links to your answer as links can be down in the future.
  • xuiqzy
    xuiqzy over 4 years
    "approved NIST hash algorithms." A good hash algorithm is not the same as a good password hashing / key derivation function algorithm!
  • Phoenix
    Phoenix about 3 years
    The stackoverflow link is dead.
  • WalksB
    WalksB almost 3 years
    @xuiqzy I don't see why they aren't the same, assuming no memory leaks and a strong (hard to guess) initial password.
  • Philipp
    Philipp over 2 years
    @xuiqzy Right the NIST source that actually suggests the SHA256 is stating: "This standard specifies hash algorithms that can be used to generate digests of messages. The digests are used to detect whether messages have been changed since the digests were generated.". This is different from password hashing. This answer has some good points but is mostly misleading which is why I ultimately downvoted it.
  • xuiqzy
    xuiqzy over 2 years
    @ZaidGharaybeh A good key derivation function also helps to make brute force on a non-perfect password significantly harder. This idea is even present in the relatively old PAM SHA-crypt algorithm which also has rounds. This objective is not achieved with a a simple and fast hash algorithm. If your password is really hard to guess, you could of course just use salted md5, but practically, you cannot assume all users to have really strong passwords and it is best to do your best to still make them as secure as possible against attackers.