2

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.

Mohamad Haidar
  • 349
  • 6
  • 13
  • 10
    None of the above. http://security.stackexchange.com/questions/211/how-to-securely-hash-passwords/31846#31846 – Cthulhu Aug 10 '15 at 09:08

2 Answers2

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.

Community
  • 1
Rory McCune
  • 60,923
  • 14
  • 136
  • 217
  • Just as a reference: https://www.freerainbowtables.com/en/tables2/ – Purefan Aug 10 '15 at 09: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!!! – Mohamad Haidar 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) – Rory 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 'SO- stop being evil' Aug 10 '15 at 12:02
  • @Gilles and @Rory Thanks a lot for explaining but also I am wondering that I can use the salt with sha512 for example sha512(pass+salt) so I think in this case the hashed password will be protected against the rainbow attack and the similar attacks while the Thomas says that they are not appropriate for reasons and one of the reasons is that they are `unsalted` but in that case it becomes salted. please bear with me I am new to these topics and I need some explanations :). – Mohamad Haidar Aug 10 '15 at 12:09
  • 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 'SO- stop being evil' 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.

boleslaw.smialy
  • 1,627
  • 2
  • 15
  • 25
  • 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 09: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 06:33