Hello,
Thanks for the pointers. Based on the previous discussion and the
comments at Simon Willison's blog on ratelimitcache, here is a first
draft of my proposal:
1. Considering that Django's admin and default login schemes are
currently unprotected against brute force attacks by default, and
2. Many users implement Django out of the box with an admin open to
brute force attacks,
3. We aim to protect Django users and to make their projects safe by
supplying an optional brute force protection mechanism. Which by
default is: on? Or off?
4. After x failed login attempts, protection kicks in. x is a
configurable amount of times, which by default is 3?
5. Failed logins are either stored in a database (which works well for
small systems and protects against slow distributed attacks), or in
memory (for large systems). Default: use the database? Because most
users operate on small systems?
6. We protect against the following scenarios:
a. Login attempts coming from many IP-addresses and targeting a
single user account;
b. From a single IP-address, targeting a single user;
c. Single IP-address, more than one user.
Case 6a and - in a lesser extent - 6b are strong indicators for a
brute force attack. Case 6c might be brute force, but might also be
triggered by many users behind a proxy.
7. Protection may consist of:
a. denying access for x minutes for a given user or IP-address. x
is configurable, and by default: 5 minutes?
b. adding a sleeptime to login requests (mentioned several times,
but sounds very weak to me, because it can be easily passed by opening
a new connection?).
c. logging it, and/or notifying the admin
d. adding a captcha to login form
8. Protection should be configurable as well. By default: use a
captcha? Using a captcha prevents an attacker from using the denial
trigger for a DoS-attack.
9. Rate limitors should be generably applicable, to all views.
10. Final question:
Should this be in Django contrib? I argue in favor, in order to
protect the innocent and keep everyone safe. django.contrib.security
seems a proper place to me. There are several rate-limiting
implementations in the wild, but unfortunately they are not often
used. For example, compare the numbers on django-packages for django-
axes, brutebuster and ratelimitcache against a commonly used
application like south or django-debug-toolbar.
I would be very glad to hear your comments. Please let me know of
anything else I did not cover and should have, and please let me know
your answers to the many questions I raised.
Thanks for your help! Goodnight to you,
Wim
--
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.
