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-
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...
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
Repoze-dev@lists.repoze.org
http://lists.repoze.org/listinfo/repoze-dev
