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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
