Re: Brute force attacks

[Paul McMillan]

I go back and forth on this issue. Unlike CSRF, there's never going to
be a one size fits all solution for this type of problem. Different
organizations have widely varying requirements, and while I prefer
rate limits, that won't satisfy the auditor whose checklist requires
permanent lockout after X attempts.

That said, Django's current approach of "figure something out
yourself" means that most installs don't get any work in this realm.
We can't defend against every attack scenario, but if we can improve
the most common areas, it will be a substantial gain.

I'm quite interested in working to get better protection into core. I
agree with Rohit that throttling/rate-limiting is going to be where
Django finds a good balance between intrusiveness and security. In
larger systems, this task is often taken care of by the firewall in a
generic one-size-fits-all fashion, but if Django is doing the
limiting, we can provide more specific protection, especially for
users who don't have fine-grained control over their firewall.

If we build a rate limiter into core, it will encourage users to make
use of it in their own projects. It will also allow us to rate limit
other areas of core to improve security - passwords are far from the
only thing susceptible to brute force, and the same framework may be
useful to prevent or discourage DoS.

We need to be careful to provide permissive defaults. Leave the knobs
exposed for organizations which require draconian measures, but for
the average user, convenience trumps security.

At the expense of creating more work, I think that we need to agree on
several facets of the problem before we go writing code:

1) Which attack scenarios do we protect against?

A single machine high-rate attack? A high-rate distributed attack? A
slow distributed attack?

The first of these is the most likely attack - it's easy to implement,
and doesn't require extensive resources or patience. Defenses against
it will also apply (to a lesser extent) in the case of a high-rate
distributed attack. Measures like locking accounts after a number of
login failures prevent the slow attack, but they inconvenience users
and open a very nasty avenue for DoS. I don't know of measures Django
could take which would provide an acceptable balance between
completely preventing this attack and avoiding inconveniencing users.

2) How do we balance protection against DoS concerns?

Since Django installations are usually public-facing, Denial of
Service issues are often a larger concern than brute force attacks
(the entire site being unavailable vs. some number of compromised user
accounts) I strongly oppose the addition of any code which makes
Django significantly more vulnerable to DoS out of the box, even if it
does improve security.

3) What is the appropriate response to an attacker?

Lock the account? Deny access to the whole application? For how long?
Log the attack? At what threshold? We rapidly get into areas that are
in the domain of a full-blown Intrusion Detection System. I think that
Django needs a very minimal set of features in this realm. Log the
attack when over a certain threshold (and log verbosity), block the IP
for a limited period of time, and move on.


In light of these issues, I think that the appropriate solution for
core will be:

* lightweight - we can't compromise performance here. The solution
should be memory-based, and should not write to the database or disk
in most cases. I'm perfectly fine with requiring caching to be enabled
to get protection.

* generic - we should be rate limiting other areas of core, and it
makes sense to provide a way for developers to easily limit their own
applications.

* limited in scope - Django includes many batteries, but it shouldn't
include a full-blown IDS. Throttling and logging for events
significantly outside the norm are enough protection. Anything more
complex becomes application specific.

* pluggable - we can't be all things for all people. We need to design
an interface that is flexible enough to allow people to implement
their own particular set of rules. We do this already in other areas:
databases, caching, sessions, etc. If we can provide a good generic
interface for this, we can include other backends with different
behaviors as they evolve in the community.

So, the tl;dr is that Django needs to include a simple rate limiting
component that is trivial to enable to discourage many brute-force
attacks. I'd like to help make this happen.

-Paul

-- 
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.

Re: Brute force attacks

[Rohit Sethi]

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  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 
> wrote:
>
> > On Sat, Mar 5, 2011 at 5:56 AM, 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 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 othe