Prevent registered email address enumeration via user registration form

As i'm currently working on #1521996: Password reset form reveals whether an email or username is in use, i can also handle this issue.

Because there the patch from #1521996: Password reset form reveals whether an email or username is in use is needed this issue is currently blocked until it is commited.

I think the privacy concern here is somewhat overstated, given that Drupal does not verify email address. Once I have an account on a Drupal site, I can edit the account and change the email address to president@whitehouse.gov. That doesn't prove that Barack Obama or his staff are members of the site.

With #85494: Use email verification when changing user email addresses it would be more of an issue though.

Slightly broadening this. The forgotten password form shows an error if an e-mail address isn't registered, which is the opposite of the registration form but amounts to the same thing for the 'is this person registered on this website' check. Can split into separate issues later, but the bug's not really fixed until both registration and password reset have similar behaviour.

Double checked with the security team and there was consensus this could stay public since it's not a vulnerability as such.

#1521996: Password reset form reveals whether an email or username is in use already has an in-progress patch for the password reset form, so if this is going to remain a separate issue (which seems OK to me) it probably should focus on the registration form only. Or if they're going to be combined, this should be marked as a duplicate.

I think this is very hard to solve. Even big sites such as Github are revealing if an email address is already taken on their registration form.

How about making it harder to check a lot of e-mails by progressively making the response slower and slower? For example, first check could respond after five seconds, the next after ten seconds, etc. After five attempts, the IP involved could be blocked for one hour.

I think if you have open registration then preventing user enumeration is not as much a concern as with the password reset. That form is useful on every site but once you have user registration at some point you're going to have to deal with telling some an email address is already registered.

I think a potentially interesting avenue to explore is the email verification avenue detailed in the issue summary. But even this is a downgrade in usability.

@alexpott with all respects

you're going to have to deal with telling some an email address is already registered.

this is not a direct consequence of the previous.

Several customers' several security teams have raised concerns about all those places where Drupal does/did expose information about existing accounts for non-evaluated users, although it must not. Several other enterprise systems work in a way that they provide the same confirmation message for those accounts that do exist and for those that do not. In case of an error (e.g.: a real user registration failed) users can still contact support.

https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Ap...

We're also facing this as customer need. This is crucial for the standig of the Drupal framework in GDPR legislations.

Yes, this is a problem when work with European Union public institutions, sometimes they report email enumeration as a security flaw, and we have some projects where we use hook_form_alter to owerrite #validate and #submit to display the same message when the user enters a valid or invalid email or username.

An alternative solution could be to add a configurable error messages in UI as we have configurable messsage emails on register, then if you want the same message in both cases, simply set the same message error in site settings.

Assigned 8 years ago...

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.

Sorry, wrong -p-level in #26

I created a MR from the latest patch.

This still needs some tests and there are some @todo in the code.