Looks like we're on the same page. I agree that we need something lightweight designed to repel brute force from a single IP. Something designed to detect distributed attacks would require more overhead and monitoring and probably doesn't belong in core. That said, I believe we should think about logging error messages using OWASP AppSensor detection point codes (http://www.owasp.org/index.php/ OWASP_AppSensor_Project#tab=Detection_Points) so that a third party monitoring tool can detect an attack on the application. Perhaps one day we could extend this standardized security logging to authorization failures as well.
We balance against DoS by slow incrementing the timeout period. We'll certainly need to experiment with this to get sensible values, but I'd suggest thinking about doubling the timeout period for every successive failed attempt starting from some configurable value such as 5 seconds up to some configurable maximum such as 4 hours. Ideally throttling wouldn't kick until at least three failed attempts (also configurable). To reiterate, all numbers above are just examples - we'll need to test in some real world conditions to figure out the best default values. On Mar 6, 7:46 pm, Paul McMillan <p...@mcmillan.ws> wrote: > 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.
