Re: How to secure passwords?

[Sebastiaan van Erk]

Jeremy Levy wrote:

Don't use MD5:

http://md5.rednoize.com/

328b78157026ea76f87d3f2d7111dfb1

j

I REALLY don't get your point.





GXSYvmzz0y

Then take the plaintext password, i.e., "test123" and append it to the salt:

GXSYvmzz0y$test123

Now make an MD5 hash:

ca62c4bd0a5094d9198112a6ce6ab4f4



GXSYvmzz0y$ca62c4bd0a5094d9198112a6ce6ab4f4





Regards,
Sebastiaan

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: Now prepend the salt to the hash, and store this in the database. In other words, store this: 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.

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

smime.p7s
Description: S/MIME Cryptographic Signature