Code

Opened 3 years ago

Closed 21 months 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.

Attachments (0)

Change History (12)

comment:1 Changed 3 years ago by russellm

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted

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 3 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 3 years ago by lukeplant

  • Type set to New feature

comment:4 Changed 3 years ago by lukeplant

  • Severity set to Normal

comment:5 Changed 3 years ago by davidfischer

  • Cc djfische@… added
  • Easy pickings unset

comment:6 Changed 3 years ago by davidfischer

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 3 years ago by jacob

  • milestone 1.3 deleted

Milestone 1.3 deleted

comment:8 Changed 3 years ago by PaulM

  • 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 3 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 3 years ago by PaulM

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 3 years ago by rklists@…

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

comment:12 Changed 21 months ago by ptone

  • Resolution set to fixed
  • Status changed from new to closed

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.