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 <paulosw...@gmail.com> wrote: > 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 django.contrib.auth - closed: wontfix) > http://code.djangoproject.com/ticket/5787 (BCrypt password hashing > support in Django - closed: duplicate) > http://code.djangoproject.com/ticket/6028 (add compatibility with > glibc2 MD5-based crypt passwords - new ) > http://code.djangoproject.com/ticket/9101 (Improved salt generation > for django.contrib.auth - closed: wontfix) > http://code.djangoproject.com/ticket/9194 (Allow additional hashing > algorithms for passwords - closed: duplicate) > http://code.djangoproject.com/ticket/13969 (auth module should use > longer salt for hashing - new) > > Some of the arguments being made for this feature have been a bit > misleading and most of them pre-date the NIST requirements changeover. > I think the summary I made before gives the most clear overview of the > current situation: as it currently stands, if you get access to the > contents of a Django user table, you can decrypt the passwords very > cheaply/rapidly. > > Looking at the code of existing solutions to this it seems like the > following would be a reasonable approach: > > * 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. > > To use SHA2-512 by default requires a larger password db column. That > might be reasonable and would be a better choice. Additionally we > could look into using Drepper's key strengthening algorithm of SHA2 by > default to make django brute-force resilient out of the box. It should > also be noted that an algorithm like bcrypt stores the salt in with > the hash and therefore the salt column is not used. > > It seems like we have people motivated to do the work. We need a > design decision made by a core dev that this is an acceptable > approach. > > -Paul > > -- > 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.
