I've had a look at your patch, and I've noticed a couple of security  
holes...  If your only desire is to prevent eavesdropping of  
passwords, I suggest you use SSL, as this is a system that actually  
works (if used correctly).
For each issue, I'll address the problem as if it stands apart to give  
a clear idea of the problems:
* `if cleartext_password.startswith('{SHA}'):`
    The hashing system is entirely optional at the client level, so  
you don't provide password protection for all clients.

* The challenge used for verification is the challenge supplied by the  
client.  This defeats entirely the point of a challenge.  I see you do  
some calculations to restrict the range of possible challenges (based  
on time), but a challenge response only works if the challenge is  
random and server supplied.  If not, then it's vulnerable to pre- 

* You're performing an HMAC with the challenge as the key.  The  
purpose of an HMAC is to provide authentication of the message in the  
case of a shared private key.  In this case, the key is public (as  
it's sent over the wire) and that means that there is no difference  
between this HMAC and a standard hash.

* In the case of a hashed password, you perform an HMAC of the hashed  
password.  In a standard hashed password system, the user must know  
the clear text password in order to log in.  The point of the hash is  
to prevent authentication in the case of a database leak.  In your  
system, the hashed password is sufficient to login, and so you've  
removed the protection that password hashing provides.

* While it's true that using a different key per request means that  
attackers who sniff the HMAC won't be able to use rainbow tables to  
compute the password from the HMAC, the passwords are still stored as  
standard hashed passwords, and that means that a db leak leaves all of  
your accounts compromised.  With salted hashes, that is not true...

Douglas Mayle

On May 20, 2009, at 12:07 AM, Paul Johnston wrote:

> Hi,
> Your timing is interesting, I'm just about to submit a patch to
> support JavaScript hashing of passwords, which interacts with this.
> If you use random per-user salts, which is the common approach, JS
> hashing requires an Ajax request at login. Not an enormous problem,
> but not ideal either.
> If the salt is hmac_sha1(master_salt, user_name) or some variant of
> this, you get the same benefits of salting, but avoid the ajax request
> at login. master_salt is a site-specific value.

This is only true as long as the secret is not known.  As soon as the  
secret is made available to the client (as in javascript hashing)  
there are no longer any benefits to using an HMAC...

> Paul
>>> So, I've finished it off and submitted the patch to issue 85:
>>> http://bugs.repoze.org/issue85

Repoze-dev mailing list

Reply via email to