Re: Ticket #21289 - Login rate limiting

[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

On Tuesday, April 5, 2022 at 4:04:54 PM UTC+2 jacob...@gmail.com 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 
> 
> .
>
> 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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/3ca88e7e-70a9-4ba0-8521-cac5f231cb42n%40googlegroups.com.

Re: Ticket #21289 - Login rate limiting

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


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-developers+unsubscr...@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 
.


--
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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/25495738-17c0-11e8-22ed-6c17dd3862fd%40posteo.de.

Re: Ticket #21289 - Login rate limiting

[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  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.
> 
> 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-developers+unsubscr...@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.

-- 
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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/86BEC74C-DB8D-4844-BE1F-2C176A285521%40gmail.com.

Re: Ticket #21289 - Login rate limiting

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

-- 
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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2969d9d7-d55a-44a1-999a-d987fc29c572n%40googlegroups.com.

Re: Ticket #21289 - Login rate limiting

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

-- 
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-developers+unsubscr...@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.

Re: Ticket #21289 - Login rate limiting

[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

On Monday, 27 July 2020 at 20:25:35 UTC+5:30 Adam Johnson wrote:

> 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
>
> On Mon, 27 Jul 2020 at 12:13, Claude Paroz  wrote:
>
>> 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
>>
>> -- 
>> 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
>

-- 
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-developers+unsubscr...@googlegroups.com.
To view this discussion on the 

Re: Ticket #21289 - Login rate limiting

[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

-- 
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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/77d835d8-85bc-4c7b-ae99-9f27cb4a6543o%40googlegroups.com.

Re: Ticket #21289 - Login rate limiting

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



> On 27 Jul 2020, at 20:21, Claude Paroz  wrote:
> 
> 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
>  
> On Mon, 27 Jul 2020 at 12:13, Claude Paroz > wrote:
> 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.
> 
> 

Re: Ticket #21289 - Login rate limiting

[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
 

> On Mon, 27 Jul 2020 at 12:13, Claude Paroz  > wrote:
>
>> 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
>>
>

-- 
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-developers+unsubscr...@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.

Re: Ticket #21289 - Login rate limiting

[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

On Mon, 27 Jul 2020 at 12:13, Claude Paroz  wrote:

> 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
>
> --
> 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-developers+unsubscr...@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

-- 
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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM0YFQ1WFcJ1CMRB4SUe%3DU7DX59ZhOMa%2BoTArGEfhnaEhw%40mail.gmail.com.

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

-- 
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-developers+unsubscr...@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.