Re: How to secure passwords?

[Sebastiaan van Erk]

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


example look here:
http://www.antsight.com/zsl/rainbowcrack/

you can use various reverse tables to get the needed inputString into any md5(inputString) function to get the desired hash -

To be specific, if I provided the hash:

4a251a2ef9bbf4ccc35f97aba2c9cbda

rainbow crack would find the key: test123.

However, if I provided the hash:

36a03a8a4c00e81f03d62d8b04bbbf4d

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. 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?

Regards,
Sebastiaan

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.

smime.p7s
Description: S/MIME Cryptographic Signature