Re: Pluggable encryption for django auth (design proposal)

On Mon, Feb 21, 2011 at 9:26 AM, Jacob Kaplan-Moss wrote: > On Mon, Feb 21, 2011 at 3:23 PM, poswald wrote: >> Russ, Carl, thanks for your feedback. Russ, I understand what you say >> about not wanting to adopt crypto code because of the additional >>

Re: Pluggable encryption for django auth (design proposal)

On Mon, Feb 21, 2011 at 3:23 PM, poswald wrote: > Russ, Carl, thanks for your feedback. Russ, I understand what you say > about not wanting to adopt crypto code because of the additional > responsibility. Unfortunately, there aren't very good options. Django > contrib.auth

Re: Pluggable encryption for django auth (design proposal)

Russ, Carl, thanks for your feedback. Russ, I understand what you say about not wanting to adopt crypto code because of the additional responsibility. Unfortunately, there aren't very good options. Django contrib.auth already makes the recommendation of SHA1 which we all agree is less than ideal.

Re: Pluggable encryption for django auth (design proposal)

On Tue, Feb 15, 2011 at 3:29 PM, william ratcliff wrote: > Carl and Russ, > Thanks for the response!  Would you prefer that those of us interested in > working on this (pluggable user cryto-system) proceed from the trunk, or > from 1.2? New features are always applied

Re: Pluggable encryption for django auth (design proposal)

Carl and Russ, Thanks for the response! Would you prefer that those of us interested in working on this (pluggable user cryto-system) proceed from the trunk, or from 1.2? Thanks, William On Tue, Feb 15, 2011 at 2:03 AM, Russell Keith-Magee < russ...@keith-magee.com> wrote: > On Tue, Feb 15,

Re: Pluggable encryption for django auth (design proposal)

On Tue, Feb 15, 2011 at 2:24 PM, Carl Meyer wrote: > Hi Paul, > > On Feb 14, 1:37 am, poswald wrote: >> * Django ships with SHA2-256, SHA2-512 or PBKDF2 by default. SHA2 is >> python 2.5 compatible (due to hashlib being added in python 2.5) and >>

Re: Pluggable encryption for django auth (design proposal)

Hi Paul, On Feb 14, 1:37 am, poswald wrote: > * Django ships with SHA2-256, SHA2-512 or PBKDF2 by default. SHA2 is > python 2.5 compatible (due to hashlib being added in python 2.5) and > PBKDF2 is short enough that it could be included into the project. > This satisfies

Re: Pluggable encryption for django auth (design proposal)

Excellent summary! If the core developers agree to this, I'm happy to contribute. William On Mon, Feb 14, 2011 at 1:37 AM, poswald wrote: > Here is an overview of issues on this subject opened over the years. > Some have existing code: > >

Re: Pluggable encryption for django auth (design proposal)

Here is an overview of issues on this subject opened over the years. Some have existing code: http://code.djangoproject.com/ticket/3316 (Adding `crypt' to list of password hashes for legacy apps. - closed: fixed) http://code.djangoproject.com/ticket/5600 (Patch to enhance cryptography on

Re: Pluggable encryption for django auth (design proposal)

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

Re: Pluggable encryption for django auth (design proposal)

There are a lot of ideas and opinions, and a fair amount of confusion floating around here. Please allow me to summarize the questions and add my commentary: 1.) Should Django ship using SHA1 (with the current salt length or even with more bits added)? - I don't think so. SHA2 (256 or 512) is

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: 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: 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

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

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

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

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

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

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

Re: Pluggable encryption for django auth (design proposal)

On Wed, Dec 1, 2010 at 2:30 AM, Christopher Petrilli wrote: > On Tue, Nov 30, 2010 at 4:22 AM, Tom Evans wrote: > >> First comment is that Django already has a pluggable authentication >> stack, which already allows for this - simply define a new

Re: Pluggable encryption for django auth (design proposal)

On Tue, Nov 30, 2010 at 4:22 AM, Tom Evans wrote: > First comment is that Django already has a pluggable authentication > stack, which already allows for this - simply define a new auth > backend that tests the password in the manner you wish. My understanding of the

Re: Pluggable encryption for django auth (design proposal)

On Sun, Nov 28, 2010 at 3:14 AM, Christophe Pettus wrote: > Hi, all, > > Right now, Django's auth system pretty much uses sha1 hardwired in > (literally, in the case of User.set_password) for the hash.  For a discussion > of why a general-purpose hash function is not the best

Re: Pluggable encryption for django auth (design proposal)

I'm not going to get into the arguments about security of the various hashing methods, other than to observe that there have been some fairly misleading statements here. As far as the proposal goes, I think this is a perfectly reasonable feature request (and you should open a ticket about it if

Re: Pluggable encryption for django auth (design proposal)

On Nov 28, 2010, at 10:26 AM, Tom X. Tobin wrote: > No, I'm not thinking of rainbow tables. The key word here is > *single*. As I said before, a salt *does* help against an attacker > trying to brute-force multiple passwords from your database, since he > can't simply test each brute-force

Re: Pluggable encryption for django auth (design proposal)

On Sun, Nov 28, 2010 at 12:11 PM, Christophe Pettus wrote: >> I'm not arguing that a salt helps against brute-forcing a *single* >> password (it doesn't), but it does in fact help against someone trying >> to brute-force your entire password database (or any subset of more >>

Re: Pluggable encryption for django auth (design proposal)

On Nov 27, 2010, at 10:29 PM, Tom X. Tobin wrote: > The point is that I'm *not* assuming hardware of equivalent speed. > I'm assuming that a worst-case attacker has hardware significantly > faster than your webserver at their disposal, so I was curious if the > purported benefit still held in

Re: Pluggable encryption for django auth (design proposal)

On Sun, Nov 28, 2010 at 12:19 AM, Christophe Pettus wrote: > Let's do the math.  The space of eight alphanumeric character passwords is > 2.8e12.  Even assuming you can cut two orders of magnitude off of that with > good assumptions about the kind of passwords that people are

Re: Pluggable encryption for django auth (design proposal)

I wrote: > A dictionary attack works by consulting a precomputed set of passwords and > their hashes, (pwd, hash(pwd)). The attacker then runs down the dictionary, > comparing hashes; if they get a hit, they know the password. The salt > defeats this by making the pwd -> hash(pwd) mapping

Re: Pluggable encryption for django auth (design proposal)

On Nov 27, 2010, at 9:01 PM, Tom X. Tobin wrote: > But how far are you willing to go in your assumption of the worst-case > computational ability of your attacker? Would tuning the hash to > (say) a 10ms delay for your web server's modest hardware translate > into a significant delay for an

Re: Pluggable encryption for django auth (design proposal)

On Sat, Nov 27, 2010 at 11:47 PM, Christophe Pettus wrote: > Actually, no, the situations are really quite asymmetrical.  In order to > brute-force a password, an attacker has to be able to try many, many > thousands of combinations per second.  To log in a user, an

Re: Pluggable encryption for django auth (design proposal)

On Nov 27, 2010, at 8:05 PM, Tom X. Tobin wrote: > Your application ends up just > as hobbled by such an algorithm as a potential attacker. Actually, no, the situations are really quite asymmetrical. In order to brute-force a password, an attacker has to be able to try many, many thousands

Re: Pluggable encryption for django auth (design proposal)

On Sat, Nov 27, 2010 at 10:14 PM, Christophe Pettus wrote: > Right now, Django's auth system pretty much uses sha1 hardwired in > (literally, in the case of User.set_password) for the hash.  For a discussion > of why a general-purpose hash function is not the best idea in the

Pluggable encryption for django auth (design proposal)

Hi, all, Right now, Django's auth system pretty much uses sha1 hardwired in (literally, in the case of User.set_password) for the hash. For a discussion of why a general-purpose hash function is not the best idea in the world for password encryption, see: