On 03/04/2011 11:56 PM, 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). 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?
My development team is willing to contribute whatever is needed to get
this done if you think it's fruitful
I'm the author of BruteBuster, and I (obviously) think that an
easy-to-use bruteforce protection is needed in Django. This being said,
I'd suggest to let the code evolve from real-life usage scenarios before
being considered for inclusion in the core or in contrib. So, take your
pick (or write your own lib), see what works and what doesn't, ask
for/implement improvements, then evaluate again. Once there is a clear,
proven winner (something like South ;), then ask for inclusion in Django.
In the particular case of BruteBuster, feel free to contact me directly
with any problems/suggestions (the development of BruteBuster has been
largely neglected, due to the code working OK for our needs and lack of
interest from other parties).
On 03/05/2011 12:22 AM, Shawn Milochik wrote:
I have an immediate interest in this discussion. One of my company's
Django apps was recently subjected to an external risk assessment team
audit. They found the fact that three invalid password attempts didn't
lock out the user to be completely unacceptable.
...
Also,
the thread referred to above discusses throttling, whereas the
"recommendation" provided to us by the auditors was user lockout
requiring administrator activity (human intervention) to unlock.
I find myself doing similar audits often, and from your description it
looks like the auditors are simply going over a checklist with
prescriptions, without much consideration of what's reasonable. Such
kind of restrictive locking is ridiculous for most use-cases. Unless you
are a very large corporation/government agency/extremely high security
facility, requiring manual intervention from the administrator after 3
failed attempts would simply annoy users and prevent them from doing
their work effectively.
If there is any enforced password strength, bruteforcing would need
*lots* of attempts to succeed. If you hadn't had your coffee in the
morning, on the other hand, it is quite easy to trip over the 3 failed
attempts limit. What happens if the sysadmin is not available to unlock
your account?
On a side note, throttling vs locking - you can implement effective
locking with throttling (say, throttle rate of 3 attempts in 10**6
minutes), but the opposite is not true. I think it is clear which is the
more flexible approach.
--
Best Regards,
Emil Filipov
Cyber Security Consulting Ltd.
http://csc.bg
--
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.
