1

This question already has an answer here:

which hashing algorithm is better to use to store a password, sha256 or sha512?

I know that sha512 is more secure than sha256 but I was wondering if it has some disadvantages or it is completely better than sha256.

marked as duplicate by Mike Ounsworth, WhiteWinterWolf, Xander, user45139, SilverlightFox Aug 11 '15 at 10:16

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

14

To expand on the point that @cthulhu makes in his comment, the correct answer to this is "nether". SHA2 family hashing algorithms are not designed for password storage and unless you have no choice but to use a general purpose hashing algorithm, they should not be used.

To quote this answer the main reasons for this are

A basic hash function, even if secure as a hash function, is not appropriate for password hashing, because:

  • it is unsalted, allowing for parallel attacks (rainbow tables for MD5 or SHA-1 can be obtained for free, you do not even need to recompute them yourself);

  • it is way too fast, and gets faster with technological advances. With a recent GPU (i.e. off-the-shelf consumer product which everybody can buy), hashing rate is counted in billions of passwords per second.

  • Just as a reference: freerainbowtables.com/en/tables2 – Purefan Aug 10 '15 at 9:36
  • @Rory, in that answer he wrote that "Salting is about using not one hash function, but a lot of distinct hash functions; ideally, each instance of password hashing should use its own hash function" but what I know that salting is to use set of bytes usually (random data) with the password as additional input to the hashing function that hashes a password. so please could you explain tHt point because I got confused!!! – Mohammad Aug 10 '15 at 10:56
  • @Moh if I'm reading that correctly, what Thomas is getting at is that the use of salts stops people pre-computing the output of possible salted values (e.g. by using a rainbow table), so by using a salt you essentially modify the input so that it's not the same as another instances of the same password hashed in that way. So if I use a salt then if two users use the same password, their hashed passwords will be different (because the salt is different) – Rоry McCune Aug 10 '15 at 11:01
  • @Moh Thomas's wording makes sense from a theoretical perspective, but I see how it can be confusing. A password hash function transforms a password into a hash. If you take hash(password+salt), the result depends on the salt. So in fact each salt value defines a distinct password hashing function. The password hashing function is not e.g. pass ↦ PBKDF2(pass) but pass ↦ PBKDF2(pass, salt) – Gilles Aug 10 '15 at 12:02
  • 1
    @Moh The presence of a salt prevents attacks that target many passwords in parallel. But a password hash also needs to be slow, to limit brute force attacks against a single password. Thomas's answer explains this. SHA512(pass+salt) is not good because it's fast. – Gilles Aug 10 '15 at 12:11
2

In fact, they are the same hashing algorithm: SHA2, just with two different digest sizes.

It is "cheaper" (faster) to generate SHA256 than SHA512. So from the security perspective a potential attacker will need more time to generate all possible SHA512 hashes to brute force a hashed password from your database.

Therefore, you can consider SHA512 as more secure, but not in terms of used algorithm, but in terms of time consumed to calculate a single hash.

So the one obvious disadvantage of SHA512 is performance, but in ~99.9% applications you wouldn't see a difference, because usually programs calculate just one hash at the time.


In this PDF document on page 3/11 you can find a time table how long it takes to generate hashes for many different hashing algorithms, just to let you rough understanding of differences between them. The document isn't brand new, so the number nowadays are smaller (due to the bigger computer power). But you will see that SHA512 consumes more time than SHA256 anyway.


EDIT: Just like colleagues said in the comments below: SHA hasn't made for password storage purpose and therefore it shouldn't be used for it.

  • 1
    That table is useless when it isn't specified which SHA2 implementation was used and which CPU it was executed on. Moreover their numbers look unrealistic. SHA512 is designed for 64 bit CPUs, it is tremendously slow on a 32 bit CPU. On an Intel Atom CPU I measured SHA512 to be 7 times slower than SHA256. On a 64 bit CPU it will be the other way around. On an AMD Athlon 64 I measured SHA512 to be 50% faster than SHA256. – kasperd Aug 10 '15 at 9:59
  • Well, as faster hashing function is worse, this means that 2 wrongs make one right here: SHA512 is at performance disadvantage - because it's faster : ) – Agent_L Aug 10 '15 at 12:09
  • @kasperd : just like I wrote: this is just to have rough view on the issue. Rory's answer is better than mine in this case :) – boleslaw.smialy Aug 10 '15 at 12:27
  • Any answer that doesn't state that one should absolutely not use either SHA algorithm for password storage seems to be a very misleading response. – Neil Smithline Aug 10 '15 at 16:20
  • Adjusted my answer to be not misleading. Thanks for comments. – boleslaw.smialy Aug 11 '15 at 6:33

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