Prevent registered e-mail address enumeration via user registration form

Created on 28 September 2014, over 9 years ago
Updated 15 July 2023, 12 months ago

Problem/Motivation

In #1521996: Password reset form reveals whether an email or username is in use we try to find a solution that stops guests to use the 'Request new password' form to learn that a user with a specific email address is registered on the site.

The same privacy issue exists with the 'Create new account' form (as was pointed out by penyaskito ).

  1. Register an account with the email address .
  2. Try to register another account with the email address .
  3. You’ll get an error:
    The email address me@example.com is already registered. Have you forgotten your password?

Proposed resolution

  • Instead of displaying an error, display exactly the same success message that is used when registering with an unused email address.
    • If email verification is required:
      • In case the address is unused: No change, send the normal registration confirmation.
      • In case the address is already used: Send an email explaining something like: "You or someone else tried to register an account on example.com with your email address me@example.com. However, you already have an account on this site. Did you forget your password? Then …"
    • If email verificiation is not required (i.e., new users are directly logged in after registration):
      • If the same password is used: Just log the old user in, and maybe show a notification that the account already existed.
      • If a different password is used: This becomes ugly … (we can’t tell if the user is the same or not). Maybe we should only provide a solution in case email verification is required?

Remaining tasks

User interface changes

API changes

🐛 Bug report
Status

Active

Version

11.0 🔥

Component
User system 

Last updated about 16 hours ago

Created by

🇩🇪Germany no2e

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

    It is used for security vulnerabilities which do not need a security advisory. For example, security issues in projects which do not have security advisory coverage, or forward-porting a change already disclosed in a security advisory. See Drupal’s security advisory policy for details. Be careful publicly disclosing security vulnerabilities! Use the “Report a security vulnerability” link in the project page’s sidebar. See how to report a security issue for details.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • 🇩🇪Germany jan kellermann

    tldr

    Add 2 options to prevent information disclosure. The patch is a proof of concept with several todos.

    a) email verification disabled

    Dont show information that name or mail address are in use, just got to the front page and send an information mail to the account holder.

    b) email verification enabled

    Introducing a two-step registration.

    - In 1st step only ask for mail address and consent to policy privacy. If mail address is in use you get a passwort reset link.
    - In 2nd step after getting mail create your account.

    Long version

    I am not sure if this can be fixed without fundamental changes. The register-form is rudimentary. You have information disclosures, you have no consent for processing privacy data per default, you have no automatic routines for deletion unconfirmed users.

    We can mitigate each single point - but everytime many custom solutions or contrib modules may break. And I think almost every page has a custom solution because the register form provides only basic functionality.

    In an ideal world you have a two-step register process:

    1) In the 1st step the user enter their mail address and consent to the privacy policy of the site. They get on the screen in any case: "Thank you for registration. We send you a mail to the given address." Then a mail with register-token or password-reset will be send. (In a real ideal world this double-opt-in would be a service in core and the data would be saved encrypted). Yes, we need a flood-protection. No user user entity will be created at this point (so we have no problem with no-deletion of orphaned users (privacy violation!).).

    2) In the 2nd step the user can create their profile. If the site is working with user names (better use only mail address) you have to inform all users that they will be visible to other registered users (and they may use an anonymous nick name).

    But this would break many (most?) existing solutions.

    My proposal is to add a info-text and add 2 new options to the account settings formular.

    The patch is a proof of concept to show the possible process.

    Open todos:

    - Account-Settings-Form: The states are not working correct - please click on and off to disable correctly.
    - two-step: Encrypt / Decrypt data in keystore.
    - two-step: No mail is sent after 1st step, you will be instead redirected to the generated URL to register
    - two-step: Remove data form keystore.
    - Send mail if registration fails in process without email verification.

    The patch should apply to D10.1

    Please take this as an offer for discussion.

  • last update 12 months ago
    Patch Failed to Apply
  • last update 12 months ago
    Patch Failed to Apply
  • 🇩🇪Germany jan kellermann

    Sorry, wrong -p-level in #26

  • last update 12 months ago
    Custom Commands Failed
  • last update 12 months ago
    Custom Commands Failed
  • last update 12 months ago
    29,425 pass, 12 fail
  • last update 11 months ago
    29,425 pass, 12 fail
Production build 0.69.0 2024