Re: Pluggable encryption for django auth (design proposal)

2011-02-12 Thread Clemens-O. Hoppe
Nice read, though I would like to add one link: http://www.f-secure.com/weblog/archives/2095.html And referenced from that, http://www.golubev.com/hashgpu.htm with the quote: Recovery speed on ATI HD 5970 peaks at 5600M/s MD5 hashes and 2300M/s SHA1 hashes. That means, 2,300,000,000 SHA

Re: Pluggable encryption for django auth (design proposal)

2011-02-11 Thread Clemens-O. Hoppe
On 02/11/2011 05:54 PM, william ratcliff wrote: Wow--you're ahead of me! Is your custom auth public source? If so, may I see the repo? Also, for increasing the length of the salt, are you referring to: http://code.djangoproject.com/attachment/ticket/13969/better_salting.diff Thanks, William

Re: Pluggable encryption for django auth (design proposal)

2011-02-11 Thread Clemens-O. Hoppe
To quote the issue 5600: So I think the only thing we can do here is increase the salt size. I think anyone who feels they need more security will have to implement a custom authentication backend; building this into Django is just to fraught with danger. Yet the patch for the salt-size only

Re: Pluggable encryption for django auth (design proposal)

2011-02-11 Thread Clemens-O. Hoppe
That's a subject which comes up every few months, sadly. In a nutshell, if something requires python >= 2.5 or a lib for older versions of Python, forget about adding it. See f. e. http://code.djangoproject.com/ticket/5600 which was closed as a no-fix 3 years ago (full disclosure: I'm coh in

Re: Pluggable encryption for django auth (design proposal)

2011-02-11 Thread Clemens-O. Hoppe
Dear Eduardo, the idea of a salt is only to make certain that two users who happen to use the same password (123456, anyone?) don't end up with the same hash in order to make a pre-computation (password lists or rainbow tables) infeasible. yet given the short salts in django, it's not really