On Sat, Nov 27, 2010 at 10:14 PM, Christophe Pettus <x...@thebuild.com> wrote: > Right now, Django's auth system pretty much uses sha1 hardwired in > (literally, in the case of User.set_password) for the hash. For a discussion > of why a general-purpose hash function is not the best idea in the world for > password encryption, see: > > http://codahale.com/how-to-safely-store-a-password/
Completely leaving aside the potential benefit of allowing different hash algorithms, I think the specific argument made by the author of that article, along with their proposed solution of an "intentionally slow" algorithm, is the wrong approach. Your application ends up just as hobbled by such an algorithm as a potential attacker. If you're choosing a slowdown factor based on your worst-case attacker, you're likely to significantly impair the ability of a website running on hardware that's not as fast, especially if you're authenticating users all the time. I think there are better potential solutions to concerns about password cracking. Django already salts the hashes, which is asymmetrical in a good way: it helps complicate brute force attacks without slowing down Django's ability to test a given password. Better password policies can also help; e.g., each additional letter you require in your users' passwords exponentially increases the space of passwords that need to be brute-forced. In cases where your attacker doesn't have direct access to the database, you can greatly slow them down by only allowing a certain amount of login attempts in a given time period. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.
