[D7] User edit form does not use flood control and allow for password brute force attacks

Created on 10 April 2024, 6 months ago
Updated 12 April 2024, 6 months ago

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

πŸ“Œ Task
Status

Needs review

Version

7.0 ⚰️

Component
User systemΒ  β†’

Last updated 1 day ago

Created by

πŸ‡ΈπŸ‡°Slovakia poker10

Live updates comments and jobs are added and updated live.
  • Security improvements

    It makes Drupal less vulnerable to abuse or misuse. Note, this is the preferred tag, though the Security tag has a large body of issues tagged to it. Do NOT publicly disclose security vulnerabilities; contact the security team instead. Anyone (whether security team or not) can apply this tag to security improvements that do not directly present a vulnerability e.g. hardening an API to add filtering to reduce a common mistake in contributed modules.

  • Needs change record

    A change record needs to be drafted before an issue is committed. Note: Change records used to be called change notifications.

Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @poker10
  • last update 6 months ago
    2,179 pass
  • Pipeline finished with Success
    6 months ago
    Total: 1234s
    #145034
  • Status changed to Needs review 6 months ago
  • πŸ‡ΈπŸ‡°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.

Production build 0.71.5 2024