Re: How to secure passwords?

[Sebastiaan van Erk]

Jeremy Levy wrote:

> even was one...
>







Regards,
Sebastiaan

> You are correct, I'm assuming his admin has knowledge of the salt, if there Of course the "admin" will know the salt, but that does not help him reverse the MD5 hash, nor will the hash be found on the md5.rednoize.com site. So the only options left are brute force and dictionary attacks. And these are always possible and have nothing to with MD5. So what you actually meant instead of "Don't use MD5" is "Don't use weak passwords". Of course it's up to the users to use strong passwords. And unfortunately most of them don't... or they do and then stick them on their monitor. ;-) And since all of this has nothing to do with Wicket (other than the fact that many Wicket apps probably have user accounts with passwords in a database), I'm going to leave it at this. :-)

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

smime.p7s
Description: S/MIME Cryptographic Signature