Douglas Mayle <doug...@mayle.org> 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-
computation...
* 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 <b...@bugs.repoze.org>
<http://bugs.repoze.org/issue82>
__________________________________
_______________________________________________
Repoze-dev mailing list
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
