On Sat, Mar 5, 2011 at 5:56 AM, Rohit Sethi <[email protected]> wrote: > Hi all, I wanted to revisit a key security discussion. Brute force > attacks are the 7th most prevalent attack by number of incidents in > the Web Hacking Incidents Database (http://projects.webappsec.org/w/ > page/13246995/Web-Hacking-Incident-Database), which tracks publicly > disclosed breaches in web application. This is ultimately because many > applications do not have provisions to prevent brute-forcing. Django’s > out of the box admin-site authentication is very awesome – so awesome, > in fact, that inevitably people have and will continue to use it for > more than just administrative users. Clearly Django takes > authentication seriously. Can we revisit the idea of protecting > against brute force authentication out of the box? (http:// > groups.google.com/group/django-developers/browse_thread/thread/ > 7559145e8c85d8c/b96c9a81e97f333b?lnk=gst&q=account > +lockout#b96c9a81e97f333b). In particular, the idea of using > throttling such as http://github.com/simonw/ratelimitcache/ or > http://code.google.com/p/django-brutebuster/. Would you be willing to > discuss further?
I'm certainly interested in discussing it. I can't deny that Django's auth system doesn't protect against brute-force attacks; if there is something that Django can do 'out of the box', then all the better. As with any Django feature proposal, nothing will happen unless someone writes the code and drives the issue. This is essentially what happened with the thread you referenced -- there wasn't any specific resistance to the idea, but there wasn't a specific offer to help (at least, not one that was followed up with action), so the discussion ended without a resolution. If you're willing to write the code (or polish the existing code) and drive the discussions, then this could easily become a feature of the 1.4 release. I haven't given this a great deal of thought myself, but here are some initial thoughts: * Is this something like CSRF, where there should be One True Solution, Enabled By Default, or is it something where a backend/plugin interface would be more appropriate? Django has historically avoided making policy decisions, and this thread has already shown that there are multiple (and policy lawyers exist that aren't likely to be flexible on those options). * Where is the right place for this hook to exist? The two projects you reference take quite different approaches. Simon's ratelimitcache is per-view protection -- which means it's easy to accidentally forget to apply it if you have a custom login, but also more flexible because you can apply rate limiting to other views, such as an API. Emil's BruteBuster integrates into the core authentication layer, which is much more robust, but less immediately flexible for other purposes. * Is there overlap here with discussions about password hashing? There was a recent discussion about changing Django's default password hash function to something that was less susceptible to brute-force attacks. This was specifically addressing the fact that SHA1 has known weaknesses, but it only takes a small increase in computational cost to render a brute-force attack impractical. To what extent would introducing a higher-cost hashing function remove the need for specific brute-force protections in auth? Yours, Russ Magee %-) -- 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.
