Ticket #21289 - Login rate limiting

[Claude Paroz]

Hi all,

I thought a bit about login rate limiting again in recent times.
https://code.djangoproject.com/ticket/21289

We know that there are some packages (django-ratelimit, django-defender,
etc.) that can do the job, but the main issue here is to provide a
*default* behavior for any fresh new Django project.

A must-read on this subject is:
https://owasp.org/www-community/controls/Blocking_Brute_Force_Attacks

I would like to suggest one mitigation measure for default Django, which
seems to me the least controversial, considering that hard-locking by
username and/or ip address can open Denial of Service vectors which may
or may not be acceptable for some sites.

My suggestion is to add a time delay of 5 seconds in the
contrib.auth.forms.AuthenticationForm after the first failure on any
username. This choice of 5 seconds is a compromise between not too much
annoying users after a failed login attempt, and still set a significant
throttling limit for some brute force attacks. You can consider that
after a failed login, a real user will spend at least 2-3 seconds just
to re-enter a new password and re-submit the form, so the real wait
penalty should not be more than 2-3 seconds.

This is of course NOT the panacea against all type of brute force
attacks, as you can read on the OWASP article above. But it appears to
me as a reasonable measure that can be widely accepted by most Django
projects that use the default authentication form.

The WIP PR is available here:
https://github.com/django/django/pull/13242

Kind regards,

Claude
--
www.2xlibre.net

[Adam Johnson]

Hi Claude,

A delay of 5 seconds seems quite long. Often I fail to log into a site due to mis-selection of credentials from my password manager, so I can resubmit a login form within 1-2 seconds. A real rate-limiting solution has the advantage of buckets of requests per time period, allowing users a few rapid attempts before being locked.

Additionally, the default PBKDF2 hasher already enforces a (smaller) arbitrary delay via its algorithm iterations. I can't find a source but I think I remember reading it should be tuned to take about 100ms. This is about 1.5 orders of magnitude less than a 5 second delay, which is perhaps not so significant in terms of password brute-forcing (less difference than one extra password character). Not sure if 100ms is where Django's current default ends up on a modern CPU, but we probably aren't far off given we increase the iterations according to a formula that roughly tracks Moore's law.

I'd rather see something like django-ratelimit merged to core. It's more general purpose so users can reuse and customize it, and we could potentially use it for other features in Django too.

Thanks,

Adam

--
You received this message because you are subscribed to the Google Groups "Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/49b80757-9117-fa11-3f53-731af1f0c206%402xlibre.net.

--

Adam

[Claude Paroz]

Hi Adam,

Le lundi 27 juillet 2020 16:55:35 UTC+2, Adam Johnson a écrit :

Hi Claude,

A delay of 5 seconds seems quite long. Often I fail to log into a site due to mis-selection of credentials from my password manager, so I can resubmit a login form within 1-2 seconds.

That 5-secs choice is debatable, we can agree on a shorter delay. We may also wait for the second or third failure before throttling (suggested on the PR).

 

A real rate-limiting solution has the advantage of buckets of requests per time period, allowing users a few rapid attempts before being locked.

Additionally, the default PBKDF2 hasher already enforces a (smaller) arbitrary delay via its algorithm iterations. I can't find a source but I think I remember reading it should be tuned to take about 100ms. This is about 1.5 orders of magnitude less than a 5 second delay, which is perhaps not so significant in terms of password brute-forcing (less difference than one extra password character). Not sure if 100ms is where Django's current default ends up on a modern CPU, but we probably aren't far off given we increase the iterations according to a formula that roughly tracks Moore's law.

I'd rather see something like django-ratelimit merged to core. It's more general purpose so users can reuse and customize it, and we could potentially use it for other features in Django too.

Sure, that might be the better long-term solution. However, I'm afraid this will be delayed forever... (note the ticket is already 7 years old). In my opinion, a "battery-included" framework like Django should include at least a basic brute force protection. That's why I'd like to push some minimal mitigation for Django 3.2, then we can always add a more elaborate tooling set later.

Claude

[Aymeric Augustin]

Hello,

Having some basic throttling built-in would be an improvement for the vast majority of websites. Also it would plug one of the big holes in django.contrib.auth (another big one being 2FA).

Some DoS concerns were expressed on the pull request. I believe the options are:

1. use a global form validation error — this is my preference;

2. return a HTTP 429 — this requires making the protection very conservative (i.e. users should never see it in normal circumstances, like CSRF errors) or adding a new error page (which every website then has to style).

Furthermore, I think:

- We should consult with the authors of existing libraries in this space to check if the simple mechanism we're considering don't have downsides we missed and they know;

- We should focus this on usernames and ignore IP addresses, as most sites are behind a reverse proxy of some kind and no one handles X-Forwarded-For headers right (even Heroku doesn't care — when I reported they were vulnerable to XFF injection, their security team [or, more accurately, their subcontractors] didn't understand the report, even after several rounds of explanation and a working proof of concept)

- We must make sure this doesn't get in the way of users with more advanced needs. Currently the feature can be disabled with DELAY_AFTER_FAILED_LOGIN = 0, which seems fine.

Best regards,

-- 

Aymeric.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/7720e6a7-b214-4602-b576-c0277b60e749o%40googlegroups.com.

[Claude Paroz]

Le mardi 28 juillet 2020 08:31:51 UTC+2, Aymeric Augustin a écrit :

- We should focus this on usernames and ignore IP addresses, as most sites are behind a reverse proxy of some kind and no one handles X-Forwarded-For headers right (even Heroku doesn't care — when I reported they were vulnerable to XFF injection, their security team [or, more accurately, their subcontractors] didn't understand the report, even after several rounds of explanation and a working proof of concept)

What if we consider REMOTE_ADDR? In the worst case, it is not filled or filled with the same proxy address for all requests and we found ourselves in the same case where it is not considered at all. In the best case, it is properly filled and then the user is getting a bit better DOS protection. Am I missing something?

Claude

[Hrushikesh Vaidya]

Hi all,

I'm trying to work on adding rate-limiting to core as part of this year's GSoC, and I'd like to work on this 

ticket as a part of the project. I'm aiming to write an API for rate-limiting (which is a lot like django-ratelimit merged into core),

which we could use to add some default rate-limiting to the AuthenticationForm.

It seems like it's hard to add rate limiting to the form without introducing a DoS vector. The ideal solution would be a soft block

like a captcha, but that is not currently possible to do in the core. For now, I propose that we allow a small amount of login attempts

per minute - maybe 10 or so attempts per minute for each username and IP considered together, and then rate-limit using a fixed window.

The IP would come from a user-specified header configured by a setting.

I think this would work better for good actors by allowing them to try again immediately after a few incorrect passwords, and limit bad actors significantly.

We will make the rate, the key, etc. for the enforced rate-limit customizable, as you can read in my proposal for the implementation here.

Thanks,

Hrushikesh

[Jacob Rief]

How about this proposal?

Someone opens the login page. In addition to the visible fields username and password and the hidden field csrftoken we add another hidden field. This field contains the earliest (server-)timestamp a user might login, and lies in the near future, for instance now() + timedelta(seconds=5). That value is cryptographically signed.

In addition to this, we disable the submit button and add a small Javascript function which sets an interval corresponding to the mandatory login delay. After that interval expired, the submit button is enabled again.

A malicious client who bypasses the disabled button and attempts to submit the login for, will receive a HTTP response with an error code > 400.

What are the advantages?

• Django doesn't have to store any state of users and/or IP addresses attempting to log in.
• Django doesn't have to delay itself to throttle requests. This btw. is a DoS attack vector by blocking server threads.
• We transfer responsibility for delaying login requests to the client – who can't bypass them.

[Hrushikesh Vaidya]

On Tuesday, 5 April 2022 at 19:34:54 UTC+5:30 jacob...@gmail.com wrote:

• Django doesn't have to store any state of users and/or IP addresses attempting to log in

We would still have to keep track of the rate of requests made by each user and/or IP if we want to respond with a > 400 

status code for a malicious client who bypasses the disabled button. So in effect this seems like rate-limiting on the backend

as well as (somewhat) on the frontend. Plus we would have to maintain some extra bit of JavaScript, and the quirks that come with it.

In my opinion, limiting the rate of requests to a small amount per minute should be a good enough initial solution,

and also solves the challenges raised in the discussion so far (to some extent).

[Fran Hrženjak]

Having a 5 seconds “forbidden window” could be bad UX for users with password managers (like LastPass, or even just Apple’s built-in whatever-they-call-it fingerprint-scanning password autofill). It often takes about a second to submit the login form in such cases.

Maybe 1 second interval would work, considering that some time will have been already used up even before the page renders. But this probably doesn’t solve the original issue.

 

Fran

On 05.04.2022., at 16:05, Jacob Rief <jacob...@gmail.com> wrote:

How about this proposal?

--

You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/b64d44a3-c7dd-4f9a-bf4f-1b8e9818fb64n%40googlegroups.com.

[Tobias Bengfort]

Hi Jacob,

I actually do like that idea! I don't think it is a good default for
django in general, but I would be interested in a reusable app that
implements this. Is this already available somehwere?

thanks,
tobias

On 05/04/2022 16.04, Jacob Rief wrote:
> How about this proposal?
>
> Someone opens the login page. In addition to the visible
> fields username and password and the hidden field csrftoken we add
> another hidden field. This field contains the earliest
> (server-)timestamp a user might login, and lies in the near future, for
> instance now() + timedelta(seconds=5). That value is cryptographically
> signed

> <https://docs.djangoproject.com/en/4.0/topics/signing/#using-the-low-level-api>.

>
> In addition to this, we disable the submit button and add a small
> Javascript function which sets an interval corresponding to the
> mandatory login delay. After that interval expired, the submit button is
> enabled again.
>
> A malicious client who bypasses the disabled button and attempts to
> submit the login for, will receive a HTTP response with an error code > 400.
>
> What are the advantages?
>

> * Django doesn't have to store any state of users and/or IP addresses
> attempting to log in.
> * Django doesn't have to delay itself to throttle requests. This btw.

> is a DoS attack vector by blocking server threads.

> * We transfer responsibility for delaying login requests to the client

> – who can't bypass them.
>

> --
> You received this message because you are subscribed to the Google
> Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to django-develop...@googlegroups.com

> <mailto:django-develop...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/django-developers/b64d44a3-c7dd-4f9a-bf4f-1b8e9818fb64n%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/b64d44a3-c7dd-4f9a-bf4f-1b8e9818fb64n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Florian Apolloner]

Hi Jacob,

I am afraid this does not help much at all. Assuming a malicious client wants to attack you, they can still just issue one request to get this "other hidden field". Then they wait 5 seconds and are free to send thousands of requests with that token (Well till it expires, then they need a new one. You can probably also not easily make a single use token because that would require state storage on the server -> back to square one). Even if we were to bind this token to source IPs etc, all you are doing is slowing down the whole attack by five seconds. And this is a static one time fee to pay for the client, which compared to the number of tries they need (over days or so) is not much.

Or do I miss something important here?

Cheers,

Florian