Hi, > 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 http://pajhome.org.uk/crypt/md5/ > 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. Paul _______________________________________________ Repoze-dev mailing list Repoze-dev@lists.repoze.org http://lists.repoze.org/listinfo/repoze-dev
