Hi! The scenario that I am considering is when the attacker has your database--can they compromise the passwords in it? While I believe that a salt will protect you against a "Rainbow Table" attack, I'm not convinced that it will protect you against the brute-force attacks which are now possible. I will try to consult some experts today and see if they are willing to go on record.
William On Fri, Feb 11, 2011 at 8:10 AM, Eduardo Cereto Carvalho < [email protected]> wrote: > 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 < > [email protected]> 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 [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> 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 [email protected]. > To unsubscribe from this group, send email to > [email protected]. > 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
