I'm not an expert on the subject. But I think that the hashes security issues are olved by the use of a "salt", salted hashes are known to be a very secure way to store data.
On Fri, Feb 11, 2011 at 3:59 AM, William Ratcliff < william.ratcl...@gmail.com> wrote: > 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. > -- Eduardo Cereto Carvalho -- 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.
