Double hashing security

Question

My first question is, I've heard that hashing the string 2 times (e.g. sha1(sha1(password)) ), because the second hash has a fixed length, is it true??

My the second question is, which is safer? (var1 and var2 are 2 strings):

1. sha1(var1 + sha1(var2))
2. sha1(var1 + var2)

If it is the 1st one, is it worth the performance cost?

Answer 1

By hashing the string twice, you are increasing the risk of collisions, which is bad security-wise.

Instead of having an infinite amount of inputs leading to 2¹²⁸ possible outputs, you will have 2¹²⁸ possible inputs leading to maybe less than 2¹²⁸ outputs.

Using salt and pepper before hashing at least keeps the input to infinite possibilities. Hashing twice increases the run time of your script, and increases the risk of collisions, unless you maintain the source of infinite input.

Answer 2

• sha1(var1 + sha1(var2))
• sha1(var1 + var2)

Neither is very secure. Don't reinvent the wheel. HMAC was designed for this; in particular, it takes steps (padding, etc) to avoid issues with certain weaknesses in certain hash algorithms interacting badly with the above 'simple' implementations.

Additionally, double hashing isn't useful to improve security. Consider: at best, you'll map from one random-ish value to another random-ish value. However, if there is a collision two resulting values from the second hash are equal, you've lost security by ending up with a collision. That is, you can never get rid of a collision this way, but you can gain one.

That said, existing preimage attacks might not work against double hashing ... but! They might still work. I'm not qualified to say which, and if you're asking this here, you're probably not either. Certainly collision attacks, which are all that are practical with MD5 today, aren't hindered by double hashing.

It's best to stick with the proven algorithms that have stood up to decades of analysis, because with cryptography, it's all too easy to make something that looks secure but isn't.