Opened 6 years ago

Closed 4 years ago

#15600 closed New feature (fixed)

Add Limitations section in the auth documentation

Reported by: rklists@… Owned by: nobody
Component: Documentation Version:
Severity: Normal Keywords:
Cc: djfische@… Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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.

Change History (12)

comment:1 Changed 6 years ago by Russell Keith-Magee

Needs documentation: unset
Needs tests: unset
Patch needs improvement: unset
Triage Stage: UnreviewedAccepted

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.

comment:2 Changed 6 years ago by Rohit Sethi <rklists@…>

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

comment:3 Changed 5 years ago by Luke Plant

Type: New feature

comment:4 Changed 5 years ago by Luke Plant

Severity: Normal

comment:5 Changed 5 years ago by David Fischer

Cc: djfische@… added
Easy pickings: unset

comment:6 Changed 5 years ago by David Fischer

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

comment:7 Changed 5 years ago by Jacob

milestone: 1.3

Milestone 1.3 deleted

comment:8 Changed 5 years ago by Paul McMillan

UI/UX: unset

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.

comment:9 Changed 5 years ago by 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?

comment:10 Changed 5 years ago by 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.

comment:11 Changed 5 years ago by rklists@…

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

comment:12 Changed 4 years ago by Preston Holmes

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.
Back to Top