Re: prevent brute force attacks by acting on several failed logins, for example by using a captcha

[Paul McMillan]

> 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.

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

-- 
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.

Re: prevent brute force attacks by acting on several failed logins, for example by using a captcha

[Wim Feijen]

Hi Paul,

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

On Oct 2, 9:21 am, Paul McMillan  wrote:
> My sense is that you're conflating 2 kinds of protection here because
> 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.
>
> 

Re: prevent brute force attacks by acting on several failed logins, for example by using a captcha

[Paul McMillan]

My sense is that you're conflating 2 kinds of protection here because
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 

Re: prevent brute force attacks by acting on several failed logins, for example by using a captcha

[Wim Feijen]

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.

Re: prevent brute force attacks by acting on several failed logins, for example by using a captcha

[Paul McMillan]

(to complete my thought from the previous prematurely sent email)

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.

-- 
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.

Re: prevent brute force attacks by acting on several failed logins, for example by using a captcha

[Paul McMillan]

Since you mention passwords specifically, I think this conversation is
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


On Thu, Sep 29, 2011 at 4:05 PM, Wim Feijen  wrote:
> Thanks guys for the support.
>
> 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
>
> --
> 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.
>
>

-- 
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.

Re: prevent brute force attacks by acting on several failed logins, for example by using a captcha

[Wim Feijen]

Thanks guys for the support.

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

-- 
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.

Re: prevent brute force attacks by acting on several failed logins, for example by using a captcha

[Markus Gattol]

you don't need to start from scratch as there's 
https://github.com/codekoala/django-axes

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/iF3qq-pH80sJ.
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.

Re: prevent brute force attacks by acting on several failed logins, for example by using a captcha

[Luke Plant]

On 29/09/11 15:06, Wim Feijen wrote:
> 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/

-- 
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.

Re: prevent brute force attacks by acting on several failed logins, for example by using a captcha

[Babatunde Akinyanmi]

+1 please

On 9/29/11, Wim Feijen  wrote:
> Hello,
>
> 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.
>
> --
> 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.
>
>

-- 
Sent from my mobile device

-- 
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.