You are correct, I'm assuming his admin has knowledge of the salt, if there even was one...
On Dec 3, 2007 1:33 PM, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote: > Jeremy Levy wrote: > > Don't use MD5: > > > > http://md5.rednoize.com/ > > > > 328b78157026ea76f87d3f2d7111dfb1 > > > > j > > I REALLY don't get your point. > > So you can do a dictionary attack on MD5 hashes or brute force on short > plaintexts if you don't use a salt. Weeha. So what else is new? This > has ABSOLUTELY NOTHING to do with MD5. This works with SHA1, and ANY > other hash. That's why you use salts. > > When you store a hashed password in the database you generally do > something like this. Take a random generated alphanumeric string of 10 > chars: > > GXSYvmzz0y > > Then take the plaintext password, i.e., "test123" and append it to the > salt: > > GXSYvmzz0y$test123 > > Now make an MD5 hash: > > ca62c4bd0a5094d9198112a6ce6ab4f4 > > Now prepend the salt to the hash, and store this in the database. In > other words, store this: > > GXSYvmzz0y$ca62c4bd0a5094d9198112a6ce6ab4f4 > > in the database. To verify the password for a user, split the stored > value, use the salt to compute the required hash, and compare. > > Good luck cracking that. Your site is not going to help, and neither > will rainbow crack. > > Regards, > Sebastiaan > > > 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 > >> > >> > >> > >> > > >
