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