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.
