superdezign wrote:Zeggy wrote:My idea is to use both MD5 and SHA-1 separately, and saving two different hashes. [...]
The reason for doing this is that, if somebody were to find a collision for one hash, I think it would be highly unlikely (and maybe impossible) for that same collision to have the correct hash for the other encryption technique. I don’t really know the inner workings of MD5 and SHA-1, but I am guessing that they both work very differently, enough for this to be true.
This seems to only be effective against rainbow tables... But that's one of the main reasons that we use salting and peppering in the first place.
No, it's not "
effective against rainbow tables", RTs are just a way to do reverse lookups on hashes. If anything, having
two hashes instead of one, would
help the attacker, as it increases the probability that the hash in question will be findable in one of the RTs. Unless the two hashes are salted that is, in which case we're back to square one with no added security against RTs (in comparison with using a single salted hash).
As for the idea - it's not new (apparently the OP hasn't spent any significant time in research), and only has
limited merit against
collision attacks. The combined collision resistance is not the sum of resistances of the different hash functions (due to the implementation details of most modern hash functions, which I'm barely familiar with, just quoting here), but it's still somewhat useful if one of the functions gets too broken, the combined collision resistance will still be no less than the collision resistance of the remaining function. This is why they still continue to use MD5 + SHA1 in signing some GNU/Linux distros.
When dealing with login credentials, we do not care about the
collision properties of the hash functions, but of their
preimage-attack resistance (i.e. one-way-ness). As such, the OP has been solving the wrong problem. I already spoke about keeping two hashes. Now, if we want to increase preimage-resistance, a better
theoretical thing is to use a single function with better resistance (say SHA256). A better
practical thing is to use SHA256 because there are no (or rarer "less", haven't checked really) public RT services against it. And don't forget a good salting.