8

Is doing something like this

sha256(sha512(password+salt))

Less secure then just doing

sha256(password+salt)

I've heard it will increase collision chances.

I can think of 3 reasons to do this

  1. A hacker is less likely to have a rainbow table for it
  2. sha256 returns a shorter string then sha512 (save space in database)
  3. It will take more time to compute the hash
James T
  • 1,853
  • 1
  • 17
  • 26
  • The chance of collision may be increased slightly but insignificantly in the case of small data like a password (because of the extra salt). Think of it this way, if you are using SHA-256 you are expressing any amount of data with only 256 bits. You can only express so many combinations with 256 bits (i.e. 2 to the power of 256). After that you get collision, a hash algorithm has a fixed output bit size and something has to be doubled up. – Bernie White Jun 21 '12 at 08:30
  • To clarify, 2 to the power of 256 is permutations of the hash function output not the input. – Bernie White Jun 21 '12 at 09:23
  • 1
    Just want to point out that those 2 functions will use the same amount of space in the DB. But even if you were to compare the output of sha256 vs sha512, the difference is only 32 bytes per user. That's merely a 32 MB difference for every million users you have; i.e. it's negligible. – TTT Feb 03 '16 at 17:37

6 Answers6

7

This feels like re-inventing the wheel, and I doubt will achieve any tangible increase of security. The designers of those functions really considered all those aspects when creating those secure hash functions.

  1. The addition of salt helps fight against rainbow table. Using two hash functions instead of one is useless as it still allows the computation of a rainbow table. Only a good random salt prevents and attacker from doing so.
  2. If sha256 produces the right length for you, then use it. You're not gaining much by using sha512 beforehand. Your search space / entropy depends primarily on the password anyway.
  3. This is also negligible. If you want to increase computation, you'd have to use a hash function like bcrypt that adds a computational workload. Hash functions are generally very fast.
OliverS
  • 131
  • 3
Yoav Aner
  • 5,299
  • 3
  • 24
  • 37
  • Is there a way to comment on the edits to my answer? It seems more than just spelling and grammar... – Yoav Aner Feb 14 '12 at 13:11
  • I know this is really old, but isn't the whole reason for salting passwords so that if the database holding them is compromised, people don't learn what the actual passwords were? In which case, isn't double hashing more effective because how would the hacker create a reference table if they don't know how you made the hashes? – Aunt Jemima Aug 13 '18 at 02:24
6

Collisions are not relevant for password hashing. Forget about collisions. Security here builds on resistance to preimages, not collisions.

About your "three reasons":

  1. The attacker being less likely to have a rainbow table: since you are using salts, the attacker does not have rainbow tables, or any other kind of precomputed table. That's the whole point of the salt: to defeat table-based attacks.

  2. The shortness of SHA-256 output: if you are short in space, you can also truncate the output of SHA-512 to whatever length fits you. Preimage resistance will be adequate if you keep at least 12 bytes or so (that's 16 characters if you encode the output with Base64).

  3. About computation speed: that's a glimpse of the truth. Making the hashing process slower is a good idea; but, in reality, you have to make it much slower than that. Don't make two hash function invocations; make two millions.

Of course, instead of reinventing the wheel, it is much better to use the good algorithms which have been designed to solve the problem of password hashing; this means bcrypt or PBKDF2. These algorithms have sustained years of analysis by enraged cryptographers, who found nothing deadly in them. A homemade scheme cannot boast as such.

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
1

As Yoav pointed out this scheme is basically useless for your intents and in a worst case scenario even hurts your security by reducing the entropy of the given password.

The only way I can image to improve security by using more than one hash function is to store all hash results separately and compare them all when authenticating. Preferable different algorithms like sha, md5 and bcrypt.

hash1 = sha512(password + salt1)

hash2 = md5(password + salt2)

hash3 = bcrypt(password + salt3)

This way the chances of successfully finding a collision are very low.

OliverS
  • 131
  • 3
1

I think you'll be fine with just the salt. This post details it much more thoroughly than I have time for, however:

https://stackoverflow.com/questions/348109/is-double-hashing-a-password-less-secure-than-just-hashing-it-once

Community
  • 1
Julio
  • 131
  • 1
  • 3
  • However, that covers hashing it using the same hash type. There may be something different using different hashes. – James T Feb 13 '12 at 22:56
0

Overkill in my opinion. SHA256 uses 64 iterations of functions over an 8 column array. SHA512 with 80 iterations over a 5 column array. There is no need to double hash because no one has been able to brute force either of these yet. Rainbow tables are not going to be useful to an attacker as long as there is salt.

Assuming 32 byte input (which is reasonable for your case - 20 bytes salt + 12 bytes password) my machine takes ~0,22s (~2^-2s) for 65536 (=2^16) computations. So 2^256 computations would be done in 2^240 * 2^16 computations which would take

2^240 * 2^-2 = 2^238 ~ 10^72s ~ 3,17 * 10^64 years

https://stackoverflow.com/questions/6776050/how-long-to-brute-force-a-salted-sha-512-hash-salt-provided

So to really protect yourself, all you have to do is make the total size of your string large, like 32 bytes, and you wont even have to worry about that.

Check this out to understand just how crazy SHA-series functions are:

http://csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf

Community
  • 1
Dan Kanze
  • 135
  • 9
  • Both of them are far too weak. You should use several thousand iterations, and not just one or two. When hashing passwords you should apply key-strengthening. – CodesInChaos Aug 27 '12 at 14:13
0

I can think of 3 reasons to do this
1. A hacker is less likely to have a rainbow table for it

That's not a good defense - they can still build a table applicable to every user in your system. A better defense is using salts (which it sounds like you are).

2. sha256 returns a shorter string then sha512

Why is that a plus?

3. It will take more time to compute the hash

That's a good reason, but there's no need to use two separate hashes, and two iterations isn't nearly enough. Better would be something along the line of hashing hundreds/thousands of times, or using a hash which was designed to be slow.

BlueRaja - Danny Pflughoeft
  • 1,943
  • 13
  • 18
  • @Bubby4j: The question is about `sha256(password+salt)` vs `sha256(sha512(password+salt))`. Both use the same amount of space. – BlueRaja - Danny Pflughoeft Feb 13 '12 at 23:32
  • 1
    @Bubby4j - How so? - Neither sha256 or sha512 have a known attack against them. So what it uses "less" space in your database. Space is cheap.....As Danny points out your two examples use the same amount of space so sha256 using less space is not a factor in your decision. As people pointed out using using sha256 on the value generated by a sha512 is not really going to increase your security. – Ramhound Feb 14 '12 at 17:06