prevent brute force attacks by acting on several failed logins, for example by using a captcha
Wim Feijen
Would it be a good idea to write a ticket and patch to stop brute
force attacks, either by requiring people to fill in a captcha after
several failed login attempts; or by setting a time delay?
Mozilla Secure Coding Guidelines recommend in doing so, see:
https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines#Easy_Quick_Wins
Google uses a captcha and I favor that approach.
Would it be a good idea to create a ticket for this, and write a
patch?
Best regards,
Wim
---
From the Mozilla Secure Coding Guidelines:
Account Lockout and Failed Login
Account Lockouts vs login failures should be evaluated based on the
application. In either case, the application should be able to
determine if the password being used is the same one over and over, or
a different password being used which would indicate an attack.
The error message for both cases should be generic such as:
Invalid login attempts (for any reason) should return the generic
error message
The username or password you entered is not valid
Logging will be critical for these events as they will feed up into
our security event system and we can then take action based on these
events. The application should also take action. Example would be in
the case that the user is being attacked, the application should stop
and/or slow down that user progress by either presenting a captcha or
by doing a time delay for that IP address. Captcha's should be used in
all cases when a limit of failed attempts has been reached.
Babatunde Akinyanmi
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-d...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-develop...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
--
Sent from my mobile device
Luke Plant
> Would it be a good idea to write a ticket and patch to stop brute
> force attacks, either by requiring people to fill in a captcha after
> several failed login attempts; or by setting a time delay?
If you search the archives of this list you'll find a fairly recent
discussion on this. Please read that first. We will need, at the very
least, a pluggable solution with a well-defined interface, because we
will not find a one-size-fits-all solution. As such, it is not a small
feature by any means. It will require significant effort just in terms
of proposing the feature. Create a ticket by all means, but I would
suggest that a solid proposal should be thoroughly discussed here before
you start coding.
Regards,
Luke
--
I teleported home one night
With Ron and Sid and Meg,
Ron stole Meggie's heart away
And I got Sidney's leg
(THHGTTG)
Luke Plant || http://lukeplant.me.uk/
Markus Gattol
Wim Feijen
For reference, there is a previous thread "Brute force attacks", here:
http://groups.google.com/group/django-developers/browse_thread/thread/71877ef02fb7c054/0b44e048b5bf4b77
Which does not mention captcha's btw.
Luke, I'll think about it, but it will take some time; thanks for the
guidance.
Wim
Paul McMillan
related to #16860. Throttling of passwords / adding captchas
definitely falls under that ticket.
https://code.djangoproject.com/ticket/16860
We probably should include a more general rate limiting framework (or
at the very least, better instructions for configuring this in common
webservers). Unfortunately, how to do this well is a REALLY hard
problem. There's django-axes as well as Simon Willison's
ratelimitcache. Neither of them are perfectly ideal. The bigger
problem is that ANY rate-limiting framework is going to need
At the moment, if your login field is not rate-limited, that is a
configuration mistake which is between you and your webserver, and is
not within the realm of what Django tries to do. We need to be careful
not to re-implement functionality that is better left to other parts
of the stack.
-Paul
Paul McMillan
The bigger problem is that ANY rate-limiting framework is going to
need heavy customization to work for all of the different ways Django
is deployed. One size will definitely not fit all in this case.
Wim Feijen
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
Paul McMillan
you haven't made a decision. Do you want to propose rate limiting, or
a captcha? Answers to your points depend on that.
Prior to more specific work on this matter (and before anything can be
included in core), we need to address the issues in 16860. The generic
groundwork must be done first. It would be helpful to examine this
proposal in light of those concerns. What hooks does Django need to
provide to allow this to be implemented cleanly as a third-party
installable?
This needs to be pluggable because (no matter what we include), it
won't meet the requirements for a sizable subset of Django's users
(many of whom have very explicit requirements).
> Points 1-3
Our protection should be on by default if we include it in Django at
all. This means that the default configuration will be universal
enough that it doesn't get in the way for most installations.
> 4. After x failed login attempts, protection kicks in. x is a
> configurable amount of times, which by default is 3?
3 is too few for a default on a general user-facing site. Brute force
attempts try hundreds of passwords. If normal users see this
protection with any regularity, people will turn it off.
> 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?
Probably the database. An extra column on users would be the most
obvious place, but it's a no-go because we don't have migrations and
this functionality should be separately pluggable anyway. We would
need to ship with a default set to off in the base settings file, and
explicitly set it on for new projects. If it adds database columns,
that might be an argument for shipping with it disabled.
> 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.
These are all attack vectors. There's also multiple IP multiple
account slow brute force, and many other variations. Any of these
options is going to need to be quite configurable to work for most
Django users.
> 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?
Rate limiting is more user friendly than a hard cutoff like this. The
hard cutoff is easier to explain to a user, though. This allows a DoS
attack against specific users.
> 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?).
Absolutely no. Adding sleep() anywhere in Django opens nasty DoS
avenues. Sleep ties up workers for no reason.
> c. logging it, and/or notifying the admin
> d. adding a captcha to login form
Which captcha do you propose? Is there a good one which does not add
external dependencies? We can't require compiled dependencies like PIL
out of the box.
> 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.
Captchas do that. They also introduce usability issues. Do you have a
pure-python captcha which is also ADA compliant? How do you recommend
we balance the difficulty (for both humans and robots) of the captcha?
> 9. Rate limitors should be generably applicable, to all views.
Yes. This is why they are probably best viewed as a separate feature.
> 10. Final question:
> Should this be in Django contrib? I argue in favor, in order to
> protect the innocent and keep everyone safe.
I agree that Django should ship some form of login protection.
> django.contrib.security
> seems a proper place to me.
For rate limiting or captcha? The former might belong in
core.ratelimit. The captcha is probably a pluggable related to
contrib.auth.
> 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.
Yep. This is why we do need to ship something with Django. But we need
to be sure that we ship a careful, complete implementation, because
once we make a decision about the interface, we have to support it for
a long time. This is why many parts of contrib started as external
projects and stayed that way until there were clear winners.
If we can build the hooks that make it easy to build this kind of
functionality, we can get the community testing necessary to figure
out which code belongs in Django itself.
Also, we don't get to add more settings. Most of the things proposed
would require the addition of dozens of settings.
It's great to have excitement about adding this feature. It's
something Django needs, and with appropriate effort, I believe we can
build a solid foundation that will be useful to many Django users.
-Paul
Wim Feijen
Thanks for your review and remarks. I will think on it more, and will
write a longer response later.
For the moment just this quick reponse:
I was thinking of adding a recaptcha implementation, based on the work
of others, if that would work with licenses. But probably that choice
would indeed introduce an external (unwanted) dependency.
About ticket 16860, I believe that to be over my head for now. In your
opinion, is that ticket tied to the User discussion, about a more
flexible/abstract User model (ticket 3011)?
And/Or do you believe we have to deal with database migration first?
Wim
Paul McMillan
> of others, if that would work with licenses. But probably that choice
> would indeed introduce an external (unwanted) dependency.
Yeah... it's really a tricky problem. That solution is probably best
as an external app. Some users deploy Django apps with no net access
at all.
> About ticket 16860, I believe that to be over my head for now. In your
> opinion, is that ticket tied to the User discussion, about a more
> flexible/abstract User model (ticket 3011)?
It's tied to it, but 3011 is really hairy, and I believe we can do
good work in 16860 with or without the changes under discussion in
3011. I don't know when we will sort out 3011, but the stuff in 16860
can happen on a different timeframe.
> And/Or do you believe we have to deal with database migration first?
That would be nice, but I think we can work with what we currently have.
-Paul