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.