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.