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-Fix-it>
(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.
