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 matters such as including too much code.
SHA1 is not secure. This is not a nationalism issue. For example: http://www.darknet.org.uk/2010/11/sha-1-password-hashes-cracked-using-amazon-ec2-gpu-cloud/ Or, from NIST: http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html where the relevant excerpt is: *March 15, 2006*: The SHA-2 family of hash functions (i.e., SHA-224, SHA-256, SHA-384 and SHA-512) may be used by Federal agencies for all applications using secure hash algorithms. Federal agencies should stop using SHA-1 for digital signatures, digital time stamping and other applications that require collision resistance as soon as practical, and must use the SHA-2 family of hash functions for these applications after 2010. After 2010, Federal agencies may use SHA-1 only for the following applications: hash-based message authentication codes (HMACs); key derivation functions (KDFs); and random number generators (RNGs). Regardless of use, NIST encourages application and protocol designers to use the SHA-2 family of hash functions for all new applications and protocols. I have also seen discussions in other venues from people who are worried about the security of SHA1 in the event that their system is compromised, can an attacker gain the passwords in the database? The appearance of modules such as django-bcrypt: https://github.com/dwaiter/django-bcrypt/ show that this issue is becoming of more general concern. Current solutions: 1) Monkey patch: put a top level installed_app that has a listener to the class_prepared signal that performs monkey patching throughout user. This is rather ugly and it feels very fragile to me if the auth module changes internally. 2) Rewrite the Backend as Tom suggests by subclassing ModelBackend: Again, it's not sufficient. Why? If we look at the Model Backend, we see that yes, the authenticate method currently authenticates against User--but the problem is NOT the authentication per se, but rather that the User class has several methods such as: check_password, set_password, etc. that have encryption hard coded. There are admin commands associated with the User class which refer to methods with a particular encryption method chosen. 3) For users of Django who cannot (say US government agencies, people who have tight security concerns, etc.) use the current module, ignore the auth module and roll their own: This has been attempted before. However, the problem is that it is easy to make mistakes doing this and most of the functionality in the auth module is very good and simply copying most of it to make a few changes to User--and to maintain those against modules which use the user module seems rather excessive. While my first suggestion was: Move the encryption related portions of the code that are hard coded to the authentication backend. Make a default which follows best practices (I would suggest moving to SHA2 in a backwards compatible fashion) that most people will use. However, for those that want to use bcrypt for example, it would be easy for them to simply write their own backend. However, there are also merits to Paul's approach of having a mapping in the settings file. What I like about the backend approach is that it allows for graceful fallbacks as function of python version, but gives the user the ability to change the algorithm in a simple way. Also, it saves one from distinguishing between sha1 and sha1 with stretching....Perhaps a compromise would be to have a backend which looks to the settings file for the location of a method? But, if I write a patch that works and maintains backwards compatibility would it be accepted? Is it better to email it here, or to submit a ticket, claim the ticket, and then add the patch? Also, would it be better for me to work from the trunk, or from 1.2.5? This is important because of: http://code.djangoproject.com/ticket/13969 Thanks, William -- 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.
