> 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).

Although it has limitations, some people want this feature. I'm not
proposing this be the default authentication method; if you don't want
it, don't use it in your applications. The risks are well understood;
you may like to read my site for more information

>   The hashing system is entirely optional at the client level, so you don't
> provide password protection for all clients.

Sure. We could potentially have a server-side option
allow_disabled_js, with the html tweaked so the submit button only
appears when js is enabled. Not something for the first attempt
though, and in fact, I expect almost everyone would rather allow users
without javascript.

> * 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

Sure. Instead of seeing a plaintext password, a sniffer sees a hash
that they can replay in a given time window, and try to brute force
the password against. That's better than them seeing a plaintext
password. The session key is going plaintext on the wire anyway, so
replay attacks are a risk anyway.

> * 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

That's one purpose of an HMAC. Here, we're using HMAC differently, as
an alternative to sha1(password + challenge). I don't think there's
any great cryptographic advantages to this, but it is the recommended
way - I communicated with one of the authors of the HMAC RFC about
this a few years ago. Not got the mail to hand now.

> * 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

Good point. This is a serious enough weakness that the docs should
mention it, and I can look at revising the patch. But with salted
hashes, it keeps the main benefit of hashing - that a captured
password database doesn't let the attacker use your customers'
password on other sites. Remember, if an attacker has your password
database, they're pretty far into your app already.

Repoze-dev mailing list

Reply via email to