I'm not an expert, but that's correct. A too-fast or broken hash function will still be "vulnerable" to a brute force attack [1]. Salting doesn't prevent this.
Peter [1] http://stacksmashing.net/2010/11/15/cracking-in-the-cloud-amazons-new-ec2-gp u-instances/ On 2/11/11 9:57 AM, "william ratcliff" <william.ratcl...@gmail.com> wrote: > 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 > <eduardocer...@gmail.com> 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 >> <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.
