On Nov 27, 2010, at 8:05 PM, Tom X. Tobin wrote: > Your application ends up just > as hobbled by such an algorithm as a potential attacker.
Actually, no, the situations are really quite asymmetrical. In order to brute-force a password, an attacker has to be able to try many, many thousands of combinations per second. To log in a user, an application has to do it exactly once. A hash computation time of, say, 10ms is probably unnoticeable in a login situation, unless you have tens of thousands of users logging in per minute (and if this is the case, then you probably have other problems than the speed of your password hash algorithm). But that would pretty much slam the door down on any brute force attempt at a password recovery. > 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. A salt is of no benefit on a brute force attack; it's function is to prevent dictionary attacks, which are a different animal. And if you are willing to assume that no attacker can ever get access to your database, then you don't have to hash the password at all. But, as you point out, that's a separate discussion from the value of pluggable encryption algorithms. There was a time that MD5 was the perfect answer; now, it's SHA-1. Different applications will have different needs as far as how they write the passwords to disk, and having an architecture to handle this seems like a good idea. -- -- Christophe Pettus x...@thebuild.com -- 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.
