Don't use MD5: http://md5.rednoize.com/
328b78157026ea76f87d3f2d7111dfb1 j On Dec 3, 2007 12:17 PM, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote: > Korbinian Bachl wrote: > > >> However, they *CAN NOT* generate a collision for an arbitrary hash. > >> Furthermore, doing this in a limited size string (like a password) > >> adds another complication. > > > > they can and did ! - if you have a hashvalue e.g: > > > > 79054025255fb1a26e4bc422aef54eb4 > > > > you can use various reverse tables to get the needed inputString into > > any md5(inputString) function to get the desired hash - > > example look here: > > http://www.antsight.com/zsl/rainbowcrack/ > > They're using precomputed tables to speed up finding a hash from a > *known* plaintext space. For example, the 36GB md5 table allows you to > find which string of 1-8 characters from the lowercase alphanum charset > was used to generate a specific has. > > To be specific, if I provided the hash: > > 4a251a2ef9bbf4ccc35f97aba2c9cbda > > rainbow crack would find the key: test123. > > However, if I provided the hash: > > 36a03a8a4c00e81f03d62d8b04bbbf4d > > rainbow crack would *NOT* find the key: Test123, since it contains a > character not in their character set. Furthermore, it would find no key > at all if it so happens (which is overwhelmingly probably the case) that > there exists no 1-8 string lowercase alphanum string which has this hash. > > > with classic rainbow tables or hybrid rainbow tables you get a 99,9% > > chance to score a hit for under 1h time... sounds not very secure to me > > Only for specific plaintexts, after precomputing the tables. > > >> Nope, MD5 password hashes are still perfectly fine. > > > > sure? > > Yes, secure enough. In practical use, passwords are rather weak, and > there are many easy attack points (social engineering, reading passwords > from an unprotected password vault of the browser, dictionary attacks, > etc.). Hashing the password is (in general) used to hide the plaintext > from view (in a DB for example). Furthermore, anybody can gain access to > an account if they have write access to the DB by simply putting in > their own hash. > > >> > >> Hashing the password client side is actually UNSAFE. This means the > >> hash goes over the network, and somebody else can just send the same > >> hash to the server to log in without ever knowing the user's password. > > > > and its more save if the md5 sits in the RDBMS that may be breached? > > Yes again. If your RDBMS is breached you've got far more serious issues. > Futhermore, somebody sniffing a hash going of the network (especially > LAN) is *EASY*. If you have a secure setup with your RDBS, it's on a > safe network, behind a DMZ, and not accessible from the internet > directly. Apart from other confidential data that will be leaked (e.g. > credit card numbers, or whatever), I think hashed MD5 passwords are the > least of your problems. > > But I agree with one thing: since it's free in Java to use SHA instead > of MD5 (all you have to do is change 1 little string), you may as well > use SHA. > > Regards, > Sebastiaan > > > >
