Re: Design design needed: #14093 - Unable to create a new session key on higher traffic

Sorry, I stuffed up some of the numbers. MD5 is 128 bits equivalent value. UUID4 is 113. A table with enough content to cause collisions for 10k input values would probably be in the exabyte range, but the point still stands. Cache timeouts are causing this problem. -Paul -- You received this m

Re: contributing to django as a part of master thersis

I'll be spending the next two years working on a event-driven python application server. As part of this work, I'll be investigating asynchronous database calls. I'll definitely report as I make progress in that arena. I'm envisioning a patch to the ORM that allows writes to be processed in the bac

Re: Design design needed: #14093 - Unable to create a new session key on higher traffic

Do we absolutely have proof that the original problem is caused for sure by session key collisions? The assertion here is that we're generating 1 md5s and that NONE of those is unique and so the function is timing out. This is preposterous. If this were actually the case, I could generate my

Re: Pluggable encryption for django auth (design proposal)

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: Inheritance of rel fields from base classes should not cause conflicts if the base classes involved are all abstract.

Thanks for the feedback. I've opened a ticket at http://code.djangoproject.com/ticket/15279. I did take a look at #14705, but though it is related topically, there didn't seem to be a way to exploit those changes for the effect I'm trying to achieve. My patch does still need improvement, docs, and

Re: Design design needed: #14093 - Unable to create a new session key on higher traffic

On Fri, Feb 11, 2011 at 5:51 PM, Tim Graham wrote: > Tom, > > That definitely seems reasonable to me. Seems like the risk of key > collision is low enough that we shouldn't have to loop at all?  My > only concern regarding uui4 is the risk of collision with multiple web > servers.  From what I've

Re: Design design needed: #14093 - Unable to create a new session key on higher traffic

Tom, That definitely seems reasonable to me. Seems like the risk of key collision is low enough that we shouldn't have to loop at all? My only concern regarding uui4 is the risk of collision with multiple web servers. From what I've read uuid1 would prevent that. That being said, I'm not an exp

Re: Pluggable encryption for django auth (design proposal)

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

Re: FormPreview feature request/bug (Trac rejects ticket as spam)

On 11 February 2011 16:58, IanSR wrote: > Trac won't let me add this as a bug/feature request, since it marks it as > spam, so I'm sticking it here. Did you try to register with Trac and login before posting the ticket ? You shouldn't have any trouble after that. Also, there is a similar ticket f

FormPreview feature request/bug (Trac rejects ticket as spam)

Trac won't let me add this as a bug/feature request, since it marks it as spam, so I'm sticking it here. This relates to the trunk SVN version of django.contrib.formtools.preivew.FormPreview. I've spent about an hour on this and realized that it isn't an easy fix, so I'll have to leave it. Fo

Re: Pluggable encryption for django auth (design proposal)

I agree, it seems like a lot of work for individual developers to be patching django themselves for secure auth. I'd be extremely grateful to see this merged into the core. On Feb 11, 10:20 am, "Clemens-O. Hoppe" wrote: > To quote the issue 5600: >   So I think the only thing we can do here is i

Re: Pluggable encryption for django auth (design proposal)

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)

I'm not an expert, but that's correct. A too-fast or broken hash function will still be "vulnerable" to a brute force attack [1]. Salting doesn't prevent this. Peter [1] http://stacksmashing.net/2010/11/15/cracking-in-the-cloud-amazons-new-ec2-gp u-instances/ On 2/11/11 9:57 AM, "william ratcli

Re: Pluggable encryption for django auth (design proposal)

On Friday, 11 February 2011 at 10:50 PM, Clemens-O. Hoppe wrote: 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. That's not true at all. If an idea is important enoug

Re: Pluggable encryption for django auth (design proposal)

Hi! The scenario that I am considering is when the attacker has your database--can they compromise the passwords in it? While I believe that a salt will protect you against a "Rainbow Table" attack, I'm not convinced that it will protect you against the brute-force attacks which are now possible.

Re: Pluggable encryption for django auth (design proposal)

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)

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

Re: Pluggable encryption for django auth (design proposal)

I'm not an expert on the subject. But I think that the hashes security issues are olved by the use of a "salt", salted hashes are known to be a very secure way to store data. On Fri, Feb 11, 2011 at 3:59 AM, William Ratcliff < william.ratcl...@gmail.com> wrote: > Hi! I'm new to the list and h

Re: Pluggable encryption for django auth (design proposal)

Hi! I'm new to the list and have started to look into authentication. I find that I will need to patch it for my own needs, but would like to ask the opinions of others who are more familiar with the code-base than I am. I apologize if I make any mistakes in the protocol of the list in matte