> 1. The author of the patch clearly thinks that security consists of
> sprinkling magic SHA-1 HMAC challenge response pixie dust over the code
> in a random fashion. This means that any revised patch must be viewed
> with suspicion.
I don't know why you feel the need to be so rude. Let me assure you that
this "pixie dust" is not random and is in fact carefully considered.
Anyway, you have some interesting points, so I will overlook your attitude.
> The next best thing to do is to use SRP. It's the only thing that lets
> you have secure passwords on the server and secure transmission of
> passwords from the client. There's a Javacsript library available at
This is actually the first I'd heard of SRP, and I'll be looking into it
some more. A quick look at the code in Clipperz suggests this is
suggested in the past; previously considered too slow, but computers are
faster now and JS engines better. I also don't now how easy it is to
factor a 256-bit number; I will certainly be investigating this some
more. If this is how it works, a great feature is that it defeats brute
force attacks as well as storing the password securely.
After feedback on ticket 82 I will be creating a standalone library,
something like repoze.who-jscrypto. This can be a place to experiment
with such approaches - we can have challenge-response login and SRP. Or
ditch challenge-response if SRP comes out clearly superior.
I will be submitting a patch to add timeouts to AuthTktCookiePlugin, in
the next week or so. I hope this patch is less controversial.
Repoze-dev mailing list