There are a lot of ideas and opinions, and a fair amount of confusion floating around here. Please allow me to summarize the questions and add my commentary:
1.) Should Django ship using SHA1 (with the current salt length or even with more bits added)? - I don't think so. SHA2 (256 or 512) is stronger and part of the python hashlib (http://docs.python.org/library/hashlib.html). SHA1 is not recommended for hashing passwords by the cryptographic community and is also prohibited by NIST. Most developers will simply trust Django to make the right choice by default and SHA1 is not the right choice anymore. 2.) Will increasing the size of the salt help? - Without a salt, a user's password of "password" can be easily looked up in a pre-computed rainbow table. By adding a salt, you force the attacker to look have a rainbow table for each salted value. They have to have a look up an entry for each "password" + "saltvalue" combination. Increasing the size of the salt increases the size of the set of rainbow tables the attacker would have to have. A 12 bit salt set of rainbow tables is probably storable. A 128 bit salt blows up the size of the tables to "practically impossible". Since the attacker has the salt, here they will usually switch to brute-forcing the passwords. The lesson is: a large enough salt forces the attacker to switch to brute force. They will run through all of the possible passwords + salt as fast as they can. Here is where having a fast general-purpose hashing function hurts you. If your attacker can do tens of thousands of checks per second (and they can), you're in trouble. Slowing them down 10,000x means the crack goes from hours to years. http://en.wikipedia.org/wiki/Rainbow_table 2.) Should Django ship using SHA2 (256 or 512)? - While using a general purpose hashing library such as SHA2 for password hashing is certainly better than SHA1, it is probably not ideal. SHA2 is designed to be fast because it's used for things besides password hashing. A password hashing function is a better choice: Bcrypt, PBKDF2 or scrypt. They have a "parameterized cost" and allow you to tune the speed of the hashing by adding rounds to slow down brute force attacks as hardware gets faster. This is called "Key Strengthening" or "Key Stretching". Ulrich Drepper created an implementation of crypt that uses repeated rounds of SHA2 for people who needed to stay with a NIST approved function. Scrypt in particular makes it difficult even for custom built hardware to compute quickly. Some relevant reading/projects: http://www.daemonology.net/blog/2009-06-11-cryptographic-right-answers.html http://www.akkadia.org/drepper/sha-crypt.html http://www.tarsnap.com/scrypt.html http://en.wikipedia.org/wiki/PBKDF2 http://pypi.python.org/pypi/py-bcrypt/ http://pypi.python.org/pypi/scrypt/ http://pypi.python.org/pypi/pbkdf2.py/ http://en.wikipedia.org/wiki/Key_strengthening 3.) Should Django allow a new mechanism for people to swap in their own choice of hashing libraries? - Since people have varying requirements and varying restrictions, I think it would be helpful. If you look at how this problem has been approached by the community to date (to my knowledge) it is mostly by monkey patching, not by writing a new auth backend. Something like this: https://github.com/fwenzel/django-sha2/ https://github.com/dwaiter/django-bcrypt/ I know Mozilla recently opted for the SHA2/monkeypatch approach above in one of their projects (although, I'm trying to convince them to upgrade that to bcrypt or scrypt). I think an improved default and the ability to upgrade (to scrypt) or downgrade (to SHA2) depending on the developer's requirements would be ideal. 4.) How should this pluggable capability be provided? - Assuming we can all agree on the other three points, this is the open question that needs to be focused on. Here, I don't have much of an opinion yet. I'd defer to someone with more experience in Django's API design. If I can swap in bcrypt or scrypt with a few lines of configuration, I'll be happy. I'm hoping this background material is useful and gets everyone on the same page. -- 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.
