i'm sure everyone's aware of the fact that it's become easier than previously imagined to find an md5 hash collision. so if someone did get a hold of an md5 or sha1 encrypted password, they could find a collision relatively easily.

everytime something like this occurrs, some ppl suggest using multiple hashes so even if a collision is found for one hash (md5), it may be hard to find one simultaneously for another such as sha1. the argument is normally made that even this is not a good idea and it's better to just use a better algo.

since it's sorta inevitable that more algos are gonna get "solved", it isn't viable to just keep changing which hash is used. so my question is...what is wrong with storing multiple hashes for the same password and other criteria*?

eg. (table in a db)
userid
md5
sha1
len
<some other quality> (ascii sum or something)

so when a password is entered, u check that it's length matches, md5, sha1 and whatever else. so the likelyhood that a single password can be used to get past all of them is drastically reduced...and the chances of finding a collision with a key of the same length is smaller than just any valid password length (i.e. 5 - 50 characters).

wondering how everyone else handles these eventualities. php (and other languages) have md5 and sha1 in-built and although there are classes or include-ables for sha256, etc. i'd rather use a set of in-builts for this purpose.

*: it's possible that having multiple hashes of the same password could actually make it easier to figure out the real password assuming the program could co-relate them somehow, but that seems harder to accomplish.

anirudh

IF you're that worried about it, don't store hashes where they are readable without root access or db owner access.

Then use fairly strong encryption - require the user to enter a password and then a public key for triple DES.

85% of security has nothing to do with encryption. It has to do with procedures, physical security, levels of access to data, etc. Having cool encryption is only part of it. What you're suggesting won't pass a security audit without a LOT of other things behind it.

my concern was more towards someone getting (read) access to the encrypted passwords and then seeking access to the "services" which would only be possible by knowing the real password. i completely agree with what u said about having the right procedures in place and the levels of data access.

Do you have any pointers on white papers warning against multiple hash use?

As far as I know, the only danger would be this confidence that's only intuitively "secure" because it's very hard to prove the real security of an algorithm.

In the case of hash algorithms, any would be obviouslly insecure if, given a message M1, you find M2 such as H(M1) == H(M2). This is not the case with MD5 yet.

Anyway, the BSD's use this technique of storing multiple hashes for each of the ports' distribution files. Only OpenBSD has been enforcing it, but it's now the norm with FreeBSD now. They all use MD5, RIPEMD-160, SHA-1 and SHA-256. Multiple hashes make it harder to produce collisions. Please, if you have any pointers on counter-arguments let me (us) know.

haven't read any white papers warning against multiple hash use.
finding a hash collision has been done with md5...as stated in the first post. the anouncement/rumour of the program was made in aug '04 and...(Slashdot | MD5 Collision Source Code Released in nov '05). for collision checking (if i can call it that)...while it may be become easier to find a collision for an algo x s.t. x(m1) = x(m2), it would be harder (i think) to find a collision for two hashes simultaneously: x(m1) = x(m2) and y(m1) = y(m2) [notice that m1 and m2 are used for both x and y].

for another concern i had:if u did something like check the length of m1: l(m1), u're significantly reducing the pool of available combos in which to find a key providing collision. ofcourse if l(m1) is leaked along with x(m1) or y(m1) then u're making it easier to find m1 itself and not just an m2 which collides...which would be like looking for an m2 but without the difficulty of wondering which key length would do the trick. (so use some other quality).

anirudh

Yes, but this weakness applies only to arbitrary messages. We can't (still) find a collision for a chosen M. I now recall that hash functions are considered secure as long as the so-called birthday attack is the only shortcut. For a hash function of N-bits, it should take 2^(N/2) hashes to find collisions for arbitrary messages.

See http://en.wikipedia.org/wiki/Birthday_attack and http://en.wikipedia.org/wiki/Birthday_paradox

This depends on the nature of the weakness of the hash function. With MD5, the 1st found collision was of messages of equal length, with just a few bits that were different. See http://www.unixwiz.net/techtips/igui...to-hashes.html

Where did you get this one? forum?

forums, "news sites", irc, etc. i disagree with the argument coz i don't c how/why using mutliple hash checks is a bad thing (unless they took a long time to compute...which isn't the case...yet).

will respond a little later. my net connection dies in 3 mins. ;-)

anirudh