- Issue created by @poker10
- Merge request !7476Issue #3440063: [D7] User edit form does not use flood control and allow for password brute force attacks β (Open) created by poker10
- last update
9 months ago 2,179 pass - Status changed to Needs review
9 months ago 4:18pm 12 April 2024 - πΈπ°Slovakia poker10
Created an initial attempt for this in the MR.
The change I made is simple:
- if user entered current password (as that is what we care about regarding brute force attacks) and the cuurent password validation fails, then add a flood event
- if we exceed the limit for these flood events, current password no longer validate (so users are unable to "test" more password)
- user can still change other fields which does not require to enter current password even if the flood limits are exceeded
- user can use one-time login link for the password reset to clear this flood event (added as a safeguard - we can have this or not, depends how we decide)
For the flood limits, I used the existing variables:
user_failed_login_user_window
user_failed_login_user_limit
So 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.