> In that framework there is no such thing as "decrypting" an MD5 digest, > because an MD5 digest is not an encrypted version of the message to > start with. No amount of CPU power will change this basic fact -- > though CPU power can be used to do a brute force search for strings > which will generate a given MD5 value. However, as stated before, at > current levels of computing power this is not feasible for messages > beyond I think 7 or 8 characters long (don't quote me on that). One real-world example of the potential weakness of 'md5 out of the box' comes from a consultancy project I was involved in not so long back. The app in question was storing the md5 value of 4-digit PINs in the background database, and the owners of the app were quietly confident that this meant the PINs were 'encrypted' and 'secure'. Of course, there are only 10,000 possible PIN values between 0000 and 9999, regardless of whether or not they're stored in plaintext or md5 hashed form, and I guess it took me less than 15 minutes to build a reference table of all md5 hash values for the possible plaintext PINs and therefore effortlessly retrieve the plaintext PIN values from their table. Imagine their surprise. And if *I* could do it... Md5 is a very handy way of 'securing' [1] password information, but only when the plaintext value offers enough possible variation in length and / or value to make building a 'possible variations' lookup table a difficult proposition. Regards, Murray Footnotes: [1] Without wanting to get into a technical debate of exactly what constitutes 'secure' when it comes to hashing / encrypting sensitive information -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
