Add Limitations section in the auth documentation

[rklists@…]

In ​http://docs.djangoproject.com/en/dev/topics/auth/, add a "Limitations" section. Specifically include the following:

Brute force attacks
If you use Django's out-of-the-box authentication support be aware that your application is likely vulnerable to brute force attacks (link: ​http://www.owasp.org/index.php/Brute_force_attack) against individual user accounts. In the absence of external defensive technologies such as web application firewalls, you will need to write your own defense or use third-party code such as this rate limiting cache decorator (link: ​https://github.com/simonw/ratelimitcache/).

---

I'm not sure what the policy is towards suggesting third party code in the documentation. If it's not possible to point directly to the ratelimit cache then maybe a general description of a defense (i.e. throttle authentication attempts) is more apt.

[Russell Keith-Magee]

I'm not sure I agree with the exact language -- saying "your app is vulnerable" is a bit incendiary. "Django doesn't provide out-of-the-box protection against" is just as accurate, especially given that it is something that can be resolved as an external issue. However, it's worth pointing out limitations when they exist.

[Rohit Sethi <rklists@…>]

Agreed. The language you've proposed is in fact more accurate given that there might be external protections in place.

[David Fischer]

There is some overlap between this ticket and #14201. I added the note on brute forcing authentication to the security topic document.

[Jacob]

Milestone 1.3 deleted

[Paul McMillan]

It's worth noting in this ticket that most webservers provide per-url configurable throttling. I'd like to see recommendations for configuring at least apache and nginx in the docs. It's pretty straightforward. You don't need a complicated WAF to get basic rate limiting.

[rklists@…]

In your experience, does webserver throttling effectively prevent a brute force attack? For example, can an attacker still try a dictionary of the 500 most frequently used passwords for a single user in 24 hours?

[Paul McMillan]

rklists: that functionality is tracked in #16860, which is important, but not directly related to straightforward throttling.

ratelimitcache doesn't do anything the webserver itself can't do. More complicated things like account lockouts are going to require per-installation tuning, and represent a DoS vector that needs to be balanced. Throttling does discourage an attacker from trying the 500 most common passwords for your 8000 users in an afternoon. It's about incremental protection here.

[rklists@…]

Agreed - for every alternative pointed out it's also worth noting potential trade-offs

[Preston Holmes]

fixed in

​https://github.com/django/django/commit/865ff32b84316a416661abc3e3e15c753395486c#L0R1754