Ok, we'll go ahead with researching this. Expect to hear back from us within the next 2-3 weeks (if not this upcoming week)
Thanks, Rohit On Mar 5, 8:40 am, Rohit Sethi <rkli...@gmail.com> wrote: > 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) usinghttp://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.
