Douglas Mayle <> added the comment:

I've commented on this patch on the mailing list, but wanted to make sure my
concerns were recorded here:
* `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...

topic: +repoze.who

Repoze Bugs <>
Repoze-dev mailing list

Reply via email to