Best practice for hashing passwords - SHA256 or SHA512?

Asked 24/7, 2012 at 4:53 Answered 1/4, 2021 at 21:11

hash cryptography passwords sha256 sha512

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?

Buddy answered 24/7, 2012 at 4:53 Comment(2)

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. – Sorenson 21/8, 2019 at 18:8

@Sorenson wouldn't that be solved by adding a salt? – Alanalana 12/10, 2019 at 1:32

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

Eimile answered 18/12, 2013 at 13:8 Comment(5)

According to the crackstation link you posted, SHA256 is a cryptographic hash function and is suitable for passwords due to low collision probability. – Melise 28/3, 2015 at 6:15

@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! – Eimile 1/4, 2015 at 14:17

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) – Dayak 15/12, 2015 at 14:36

Folks have been down-voting this answer lately without commenting. If you think this answer is a bad one, please explain why. – Eimile 16/9, 2016 at 14:37

There's too much wrong with this answer to fit in a comment. See my answer below. Sorry. – Stimulant 9/9, 2019 at 0:50

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.

Stimulant answered 8/9, 2019 at 4:34 Comment(11)

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! – Eimile 10/9, 2019 at 14:59

-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. – Eimile 10/9, 2019 at 15:5

I had a look at both of the links you provided. Did you even notice that both authors recommend using Argon2? – Eimile 10/9, 2019 at 18:7

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. – Stimulant 11/9, 2019 at 10:59

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'. – Stimulant 11/9, 2019 at 11:4

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. – Stimulant 11/9, 2019 at 11:7

"approved NIST hash algorithms." A good hash algorithm is not the same as a good password hashing / key derivation function algorithm! – Khiva 15/2, 2020 at 17:2

@Khiva I don't see why they aren't the same, assuming no memory leaks and a strong (hard to guess) initial password. – Percentage 8/7, 2021 at 6:15

@Khiva 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. – Hamite 26/8, 2021 at 7:8

@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. – Khiva 4/11, 2021 at 20:26

Was gonna say the same thing as @Hamite before I read his comment. To add upon it, you start and end your answer saying that SHA512 is a NIST-approved algorithm. While this is true, you are not answering the question. It's not "just hashing", it's about password hashing. Your NIST link has nothing to do with the question. – Theall 8/12, 2022 at 14:54

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.

Eisegesis answered 24/7, 2012 at 5:5 Comment(6)

On my box, SHA512 is only 20% slower than SHA256. I've checked with "openssl speed sha256" vs ""openssl speed sha512". – Eimile 1/4, 2015 at 17:30

The SO link was removed "for reasons of moderation." – Bryonbryony 31/8, 2015 at 16:3

Since the linked-to SO answer was deleted, here are some other relevant SO answers: #1593108 and #20186854 – Ordnance 23/10, 2015 at 0:55

in certain cases as mentioned in this discussion SHA-512 may be faster than SHA-256 crypto.stackexchange.com/questions/26336/… – Submultiple 5/11, 2015 at 10:40

Please add the relevant passages from links to your answer as links can be down in the future. – Khiva 15/2, 2020 at 16:57

The stackoverflow link is dead. – Drubbing 21/2, 2021 at 22:45

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

Galbreath answered 21/5, 2013 at 9:44 Comment(3)

None of the proposed hash algorithms are appropriate to hash password, you should use a slow key-derivation function like BCrypt of PBKDF2 instead. – Crabbe 21/5, 2013 at 12:51

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) – Marcos 14/4, 2017 at 13:56

I did some tests confirming SHA-512 is 50% faster on 64-bit CPU: crypto.stackexchange.com/a/52646/42045 – Mclaurin 11/12, 2017 at 9:17

Outside of the really good and more practical/accurate answers regarding passwords, I have another perspective (one that I think is complementary to the others).

We use tools and companies to perform vulnerability assessments. One red flag we've had in code is use of MD5. This was not anything related to passwords... it was simply to generate a digest for a string. MD5 is nice and short, and really not a security issue for this specific scenario.

The problem is, it takes time to configure scanners to ignore these false-positives. And it is much more difficult to modify a security report written by an external vendor, in order to change the "high risk" finding to "low risk" or removed.

So my view is, why not use a better algorithm? In my case, I'm starting to use SHA512 in place of MD5. The length is a bit obscene compared to MD5, but for me it doesn't matter. Obviously, one's own performance needs in either calculation or storage would need to be considered.

As an aside for my situation, switching from MD5 to SHA256 would probably also be okay and not raise any red flags... but that leads me to my "why not use a better algorithm" comment.

Brunelle answered 1/4, 2021 at 21:11 Comment(0)

Hot tags

Godot Unity Godot Help Programming Godot 4.X GUI GDScript 3D 2D Physics CSharp Godot 3.X VR XR Projects C++

Recommended topics

Hot tags