Hi Russell, here are my thoughts on your points: 1. I do believe there should be something enabled by default. Some security conscious developers will go out of there way to integrate a third party plugin but I believe (and I may be wrong) that many developers just assume the out-of-the-box authentication is secure enough to meet their needs. I say this after 6.5 years of application security consulting and addressing common misconceptions about web app frameworks repeatedly over the years. This thread has shown that there has indeed been some policy debate, however I think you'll notice in the thread Shawn was simply referring to an audit finding - probably taken from a checklist audit - but as Richard and Emil (and others in the previous thread) point out this could actually lead to a DoS vulnerability without appropriate monitoring. I'd strongly advocate using a throttling mechanism, with the ability to turn it off and replace with a third party plug-in if somebody desires.
2. I don't have an immediate answer on this. We can investigate and come up with a proposal before we start developing / integrating 3. I think the the hashing talk was specifically about stolen stored credentials - in particular, about being able to determine many passwords from a table of stolen hashes. For brute force protection against a single account, you'd have a very slow authentication process to make it infeasible for somebody to try the top 500 passwords on a single user account. For example, if it took 3 seconds per authentication it would take less than half an hour to perform this brute forcing (http://www.whatsmypass.com/the-top-500-worst- passwords-of-all-time) using http://sectools.org/crackers.html. On Mar 5, 3:43 am, Russell Keith-Magee <russ...@keith-magee.com> wrote: > On Sat, Mar 5, 2011 at 5:56 AM, Rohit Sethi <rkli...@gmail.com> 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 ashttp://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 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.
