Re: Re[2]: MD5 Password encoding (was: Defeating Citi-Bank Virtual Keyboard Protection)

Hi, comments below.

On 8/17/05, Oleg Topchiy <edge@ua.fm> wrote:
> It's true, but if the whole database is comporomised, there is a good
> chance that vast number of the passwords won't stand against even
> dictionary attack, leave alone bruteforce. Although this method
> provides best balance between complexity and security.

A couple issues here:

1.  The database shouldn't contain the hash of just the password.  It
should store a random salt and the hash of the password+salt (or some
mix of hashing and salting like H(Salt+H(Password)), for example). 
Sometimes you will see the username used instead of a salt, but a
random salt is better because it prevents pre-computation of password
hashes or username+password hash pairs.

2.  The client should not send the hash of the password or the salted
hash.  It should receive a random challenge and usually the fixed salt
and send back something like  H(challenge+salt+password).  This
challenge should only be valid once to prevent replay attacks.  This
is essentially the system used by Yahoo! (see
http://us.i1.yimg.com/us.yimg.com/a/1-/java/login/login_md5_1_12.js).

That being said, the hashing of passwords doesn't do anything to help
in the case of a compromised client machine.  It does protect against
eavesdropping, which is a significant problem with people using
insecure wireless connections.  It is vulnerable to a MITM attack, but
while that is not overly hard on wireless, it is harder than
eavesdropping.

Have a good one.

Chuck