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

Reply via email to