Problem/Motivation
This is a backport of #2339399: User edit form does not use flood control and allow for password brute force attacks.
I think we could proceed with D7 fix independently, as there will be a slightly different approach as in D10.
Steps to reproduce
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
Issue fork drupal-3440063
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #3
poker10 commentedCreated an initial attempt for this in the MR.
The change I made is simple:
For the flood limits, I used the existing variables:
user_failed_login_user_windowuser_failed_login_user_limitSo this means we allow 5 failed current password validations every 6 hours. Not sure if this number is too low, but if yes, we can create new variables and make this limit bigger.
I have also added a test for this, which is testing user edit form and current password validations with and without entering the current password, to see, if flood control was triggered.
Here is a test only job, where one test failed as expected: https://git.drupalcode.org/project/drupal/-/jobs/1313301 (the second test does not failed, because it is testing the empty current password which is not supposed to trigger the new flood control)
The regular pipeline is green (for each PHP/SQL combination): https://git.drupalcode.org/project/drupal/-/pipelines/145034
Moving to Needs review.