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, 2011 at 2:24 PM, Carl Meyer <carl.j.me...@gmail.com> > wrote: > > Hi Paul, > > > > On Feb 14, 1:37 am, poswald <paulosw...@gmail.com> 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 NIST/US Gov requirements. > >> * SHA1 is maintained for backwards compatibility > >> * More secure hashing algorithms can be specified by defining the > >> functions to be used for 'User.set_password' and 'User.check_password' > >> as suggested above. > > > > I'm only one core dev, and not a crypto expert, but I've read the > > linked material and followed previous conversations, and here's my > > take: > > > > I don't think it's OK for Django to continue shipping with a default > > password hashing scheme which no crypto expert, as far as I've seen, > > considers adequate. People I trust to know their crypto, e.g. Thomas > > Ptacek of Matasano, consider PBKDF2 to be significantly better than > > salted SHA1 for password storage, if not quite as good as bcrypt. [1] > > PBKDF2 is simple enough (just SHA1 iterated many times) that including > > an existing pure-Python implementation in Django seems reasonable, > > removing the concerns about cross-platform and Python version > > compatibility. (It would still be best if we could get the PBKDF2 > > implementation reviewed by a cryptographer.) So I'm +1 on switching > > Django's default password hashing to PBKDF2. > > As with Carl -- I'm only one core dev, and I'm not a crypto expert, > here's my take: > > I agree that it's less than ideal for us to continue to use SHA1 given > it's known inadequacies. > > My concern with this approach is that it requires us to either > maintain or adopt an encryption algorithm. We're not just using > something from the standard library, we're taking responsibility for > the holes in a specific implementation. Even if we just adopt code > from an existing implementation, we are accepting responsbility for > finding and fixing any holes in that implementation. This is a > responsibility that can't be taken lightly, and I'm not completely > convinced that we should pick up that particular gauntlet. > > For this reason alone, I could be convinced that a configuration item > may be called for here -- e.g., registering a user-crypto library that > the default User object will use, in the same way that you can > currently register serialization libraries. > > However, that said: > > > As for the broader configurability question, I'm just fine with > > requiring a custom auth backend, which really isn't that hard, as a > > condition for customizing password hashing. So I'm not particularly > > tempted by proposals to add a new setting for this. The hardcoded > > stuff in the User model does bug me, though; I'm interested in the > > proposal to make the User model delegate that to new methods on an > > authentication backend (with backwards-compatibility fallback for old > > auth backends that don't have the new methods). > > One of the things that I want to tackle in the 1.4 timeframe is the > general problem of a 'pluggable' User model. Allowing for customizable > authentication schemes is one (of many) parts of this problem. Right > now, my focus is on getting the 1.3 release out the door; once the 1.4 > feature phase starts, I'll have a lot more time to discuss this sort > of thing. > > Yours, > Russ Magee %-) > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
