Add Username Enumeration Attack Prevention Test

Created on 24 October 2023, about 1 year ago
Updated 10 November 2023, about 1 year ago

Problem/Motivation

Some parts of the code in email_registration might be prone to username enumeration attacks, see

Drupal itself also doesn't seem to be 100% safe for this: https://www.drupal.org/project/username_enumeration_prevention

So I'm opening this as regular issue, as this
The risk is mitigated by using anti spam methods like Honeypot or CAPTCHA so that the attack can't scale well.

8.x-1.x is also affected, so the fix should be backported or 8.x-1.x should be deprecated when fixed.

Steps to reproduce

Test the existence of usernames in email_registration provided or modified forms.

Affected implementations:

https://git.drupalcode.org/project/email_registration/-/blob/2.x/email_r... seems fine!

Proposed resolution

See https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Shee... for possible solutions and how core and the contrib module handles the affected cases

Remaining tasks

User interface changes

API changes

Data model changes

Feature request
Status

Needs work

Version

2.0

Component

Code

Created by

🇩🇪Germany Anybody Porta Westfalica

Live updates comments and jobs are added and updated live.
  • Needs tests

    The change is currently missing an automated test that fails when run with the original code, and succeeds when the bug has been fixed.

  • Novice

    It would make a good project for someone who is new to the Drupal contribution process. It's preferred over Newbie.

Sign in to follow issues

Comments & Activities

  • Issue created by @Anybody
  • 🇩🇪Germany Anybody Porta Westfalica

    Update: Only the EmailRegistrationLogin checkout pane seems to be affected. Perhaps we can solve this by using a more neutral message?

  • 🇩🇪Germany Anybody Porta Westfalica
  • 🇩🇪Germany Anybody Porta Westfalica

    @Grevil and me just took a look and it's fine. The message is the same with correct user and wrong password and wrong user. So no risk here.

    But it's a good chance to add a test for this, checking all the modified forms :)

    That test should simply check that the error messsage shown is the same for all cases, so Usernames can't be guessed! I think that could ne a nice novice functional testing task?

  • First commit to issue fork.
  • @hlopez opened merge request.
  • Status changed to Needs work about 1 year ago
  • 🇩🇪Germany Anybody Porta Westfalica

    @hlopez thanks, could you please add a link to this issue in the comments and describe what the test is for - protecting us from user enumeration attacks by comparing the message to the expected core messages?

    I guess password reset should also be tested.

Production build 0.71.5 2024