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 WhiteJun 21 '12 at 8:30

To clarify, 2 to the power of 256 is permutations of the hash function output not the input.
–
Bernie WhiteJun 21 '12 at 9:23

6 Answers
6

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.

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.

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.

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.

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

About your "three reasons":

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.

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

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.

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.

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.

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.

"2. sha256 returns a shorter string then sha512 Why is that a plus?" It uses less space in a database.
–
Bubby4jFeb 13 '12 at 23:26

@Bubby4j: The question is about sha256(password+salt) vs sha256(sha512(password+salt)). Both use the same amount of space.
–
BlueRaja - Danny PflughoeftFeb 13 '12 at 23:32

I compared those two ways because sha256 is less-secure than sha512.
–
Bubby4jFeb 13 '12 at 23:34

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.
–
RamhoundFeb 14 '12 at 17:06