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):
If it is the 1st one, is it worth the performance cost?
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.
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.
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.
My feeling about this is that you're building a brick wall with a steel door, but the other walls are made of plywood. In other words, you can inject as much security as you want into hashing passwords, but there are still going to be much easier ways to crack your system. I think it's much better to take a broad approach to security instead of worrying too much about things like this.
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 2128 possible outputs, you will have 2128 possible inputs leading to maybe less than 2128 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.
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.
Hashing a string multiple times will complicate the task of the attacker in case of a dictionary attack, making it "much longer" to brute force. Your first question is not clear, but multiple hashes are not less secure because the second hash has a fixed length.
But more important than a multiple hash, the use of a salt is essential for a better security.
Concerning your second question, I would say that it is not very straightforward to say which of the 2 is the safest, I think going with the option 2 is really enough.
I am with Andrew Moore on this one. From a cryptographic standpoint, double-hashing is weak.
And I also agree with all others above who suggested to use a 'salt'.
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.