Luke, I guess the real question is what's the risk of not including it out-of-the-box? What happens if Django users *do not* go out of their way to use a third party tool to protect against brute-forcing? Seems to me that they're likely susceptible in the absence of a network device or service designed to protect against application-layer brute forcing. How many Django auth users implement one of these third party account throttling/lockout plugins today? How many of the developers who do not implement these tools are relying on django.contrib.auth to protect confidential or integral data within their applications? If the vast majority of Django apps using auth have brute-force protection in place already OR they're okay with being susceptible to a script-kiddie attack then there really *isn't* a need for this and we should drop it. My suspicion is that it's probably the opposite but I readily admit I might be wrong.
The concerns you bring up are valid - there aren't obvious answers that will work in the vast majority of cases. I'd like to think we can err on the side of being permissive: the vast majority of valid end users should not experience any impact to their authentication. This may not pass an ISO27001 audit but it's going to substantially help protect your application. One of the biggest challenge seems to be configuration, and a real desire not to add more configuration options. I have to plead ignorance here and say that I don't know if you've found other ways around this in the past. You're right that this won't work without configuration options and the ability to turn-off / use a different plugin. Perhaps another option to explore is to bundle this, along with other important security measures such as password complexity configuration, into a security package for Django rather than adding it to contrib. I would prefer not to go down this route for something as important as authentication throttling as I think many Django users believe that Django's inherent security is good enough for their needs. Again, please correct me if my assumptions here are wrong. On Mar 7, 6:48 pm, Luke Plant <l.plant...@cantab.net> wrote: > On 04/03/11 21:56, Rohit Sethi 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). > > For me, since you can implement this as an external app for most cases, > the question is: why should we include something in core or contrib? > > The answer must be either: > > 1) we need this out-of-the-box in the normal case. > 2) having multiple solutions hinders web development, rather than > fostering beneficial competition that can evolve faster than > Django's release cycle. > > Regarding 1), if we aim for something out-of-the-box, we *have* to make > all kinds of decisions, as already discussed, like: > > - on what basis to we detect brute force attacks? > > - what rates do we limit to? > > - what action do we actually take when we detect attacks? > > - where do we store failed attempts? (database, cache?) > > Most of the answers would be inappropriate in large number of cases, and > we would then need a whole bunch of settings to allow customisation to > these. At the very least, we would need to be able to disable the whole > thing, and use something else. > > Regarding 2), I don't see that having multiple solutions, even multiple > solutions in a single project, is a problem, unlike something like the > 'messages' framework that was added to contrib, where there is obvious > benefit from a single solution that provides most of the features that > most apps need. > > Further, I envisage that adding a solution to core/contrib might tend to > make it *harder* to add a custom solution, since bundled apps (e.g. the > admin) will use the bundled solution. If that solution uses view > decorators like Simon's ratelimitcache, we've hardcoded something that > might be inappropriate. > > I don't see the point of trying to add this to Django unless we can > answer these questions, but from the sounds of the thread so far, I > suspect we cannot provide sensible defaults with enough customization > hooks to make it worthwhile. > > In the end, I'm afraid this will end up as one more example of Django > "badteries" > <http://www.scribd.com/doc/37113340/Why-Django-Sucks-and-How-we-Can-Fi...> > (That presentation of Eric's is really good, BTW, video here > <http://djangocon.blip.tv/file/4112452/>) > > Regards, > > Luke > > -- > "Despair: It's always darkest just before it goes pitch black." > (despair.com) > > Luke Plant ||http://lukeplant.me.uk/ -- 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.
