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.
