Well, nobody should be using plain MD5 to hash passwords anyway. However, preimage attacks (finding an input that produces a specific hash) are still vastly more difficult than collision attacks (where the hash is not chosen in advance).

The security flaws introduced by collision attacks tend to be a bit subtler. For instance, if a digital signature scheme uses MD5 as the underlying scheme, you could generate two different documents with the same hash, convince a third party to sign one of them, and then transfer the signature to the other document.

can you clarify what you mean by "plain md5"? if someone is using md5 with crypt(3) is that ok?

i ask because of this - https://bugzilla.novell.com/show_bug.cgi?id=743715

AFAIK crypt(3) should not be using "plain" md5, it uses both a salt and variations of md5, plus the hash function is run many times so that bruteforce attacks are mitigated (it takes much more time to compute the hashes)

googling..... http://en.wikipedia.org/wiki/Crypt_(Unix)#MD5-based_scheme

I think teraflop had in mind salting.

A salt only protects against pre-computed dictionary attacks (rainbow tables). It does not offer any additional protection in this scenario.

I would recommend both salting and key strengthening.

It's not best practice (use bcrypt/PBKDF2/scrypt), but there are no known or suspected attacks on that construction and the original article does not seem likely to help in finding one.

I had always wondered about that, but it seems unlikely an MD5 could ever be spoofed in such a way that would make any sense.

I mean to say, you could find a hash that would match an existing, let say, word document. But that wouldn't be a legit word document or anything - it would likely be some random character string. The chances of changing anything in a meaningful way or adding a payload seems practically impossible to me. Is that a false assumption on my part?

Oh goodness no, there are lots of practical attacks that would work if people still trusted MD5.

For example, two self-extracting archives with the same MD5 that unpack to completely different contents: http://eprint.iacr.org/2004/356.pdf

Two postscript files with the same MD5 that print different letters: http://web.archive.org/web/20071226014140/http://www.cits.ru...

And plenty more as listed here by Peter Selinger: http://www.mscs.dal.ca/~selinger/md5collision/

3 years ago, an MD5 collision was exploited to allow the creation of a fraudulent CA certificate!

http://www.win.tue.nl/hashclash/rogue-ca/

Basically they could create HTTPS certificates for any domain (microsoft.com, gmail.com, etc) and it would be shown valid by the browser. So MD5 collisions really are useful in practical real-world attacks.

It is. The MD5 preimage attacks support arbitrary (non-common) prefixes and arbitrary common suffixes. With complex file format like a word document, it's easy enough to put a binary blob at the end of the file that doesn't affect how it looks to the user, and the content before that point can be whatever you want (as long as it's the same binary length, which is also easy enough to arrange).

There are no known "preimage attacks" against MD5. Only collision attacks. The term you are looking for is a "chosen prefix collision attack".

Huh. I hadn't known about the MD5 preimage attacks. I'd planned to use salted MD5 to generate nonces, possibly with HMAC. How unsafe is that?

that's pretty interesting, i had assumed that it would be fairly easy to create duplicate content with the same signature, but nearly impossible to make that content something usable.

In theory there are no new security implications, since you shouldn't be using MD5 for secure stuff anyway. The writing has been on the wall for MD5 for a while. This is just another interesting nail in the coffin. It's getting easier and easier to do thing with MD5 that you shouldn't be able to do.

It's still not trivial at all to introduce a payload and make it so the whole package matches a MD5 hash. Haven't seen a PoC ever do this.

Would recommend to go SHA anyway.

Several proofs of concept have been listed elsewhere in the thread.

Thanks, they weren't there when I posted. Will look into that.