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

I doubt this would add any security to it. It would increase the runtime of your script, but would not add a lot of security to the hash. Remember that when someone tries to break your hash, they don't need to find the exact value of var1 and var2, they only need to find one that results in the same hash.

Answer 2

I am no expert on cryptography, but as far as I know you will gain no security from hashing a value multiple times besides slowing down the process. So if you hash 1000 times, you will make an attack (for example a dictionary attack) 1000 times slower but this is quite irrelevant in the case of hashing once or twice.

Answer 3

Is var1 + var2 gonna be the same in an expected situation? I mean, the first proposition should be ok in that case, for you would avoid hashing collision. About being worth the cost, that's a question you should answer. Is avoiding a collision worth the cost.

About the sha algorithm, it is supposed to really scramble the results. So applying it many times shouldn't have better results, nor applying it to a "more random" input should result in better results.

Answer 4

Using just one and no salt allows it to easily be solved.

There are many large tables that contain tons of these hashes so a single hash with no salt can be solved in next to nothing.

Adding in a second hash will not help much either because once again these tables already exists with the values saved.

A dynamic salt that is added to the password will help out much more then multiple hashes. Multiple hashes do not really add much to it.

Answer 5

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 6

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