> 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
> http://sourceforge.net/projects/clipperz
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 
JavaScript RSA with a 256-bit key. This is something that has been 
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.

Best wishes,


Repoze-dev mailing list

Reply via email to