Hiding "e-mail taken" on sign-up by default

Background

Under the current default settings, when signing up for an account with an e-mail that has already been registered, the sign-up form will inform of that:

We are changing the default setting to not give away this information. Instead, the sign-up form will look like this, regardless of whether the e-mail is already registered or not:

This also affects password resets in similar ways. With the setting disabled, the form provides immediate feedback that the e-mail is in the system:

With the setting enabled it does not disclose that information:

Why are we changing it?

A malicious actor can use this feedback to perform an account enumeration, letting them know whether certain users exist on this forum, which can then let them target those users with phishing.

Won’t this affect legitimate users negatively?

The case here is if a user forgot that they already have an account, and they try to sign up or reset password using the same e-mail, which should be a relatively rare occurrence. But even then, they will just receive an e-mail letting them know they already have an account.

The change ultimately does not affect legitimate users’ ability to sign up or access their accounts.

But I prefer the old default

If you have changed this setting at any point, the new default will not override the custom setting. If you want to change back to the old default, you can set the hide_email_address_taken setting back to false.

Note: we are considering hiding this site setting from the admin settings page in the future.

9 Likes

What happens in the case where the user misremembers which email address they used to sign up?

For example, suppose the user thinks they signed up as example@gmail.com but they actually signed up as example@yahoo.com. They’ll attempt a password reset providing the email address example@gmail.com, but there’s no account with that email address.

If an account matches ted@discourse.org, you should receive an email with instructions on how to reset your password shortly.

If the user simply doesn’t receive an email in that case, then they’ll never know that they provided the wrong email address, and won’t know when/whether to try again with a different email address.

Instead, the message should simply say, “You should receive an email with instructions on how to reset your password shortly” and the user should receive an email explaining “Someone requested a password reset for example@gmail.com, but there’s no account with that email address.”

This will not allow anyone to perform account enumeration, but it would allow the user to know that they submitted the wrong email address, and to try a different one.

5 Likes

The problem with this approach is that it allows malicious actors to trigger sending an email to addresses that have never interacted with your instance, or that do not exist.

This could lead to much higher numbers of emails sent, potentially causing high monetary cost. It could also lead to a large increase in users reporting spam and a higher bounce rate, potentially causing operators like Gmail blacklisting emails from you.

5 Likes

Attackers could already do that just by registering new accounts. If the attacker knows 100,000 email addresses, they can register 100,000 accounts, and Discourse will send each one of them an activation email, which each user could report as spam.

Sending “can’t reset password, your account doesn’t exist” emails to email addresses of accounts that don’t exist doesn’t make that attack any easier or any harder.

This attack is not an issue for most sites, but, if you’re worried about it, you should use the Discourse hCaptcha plugin, which increases the cost to the attacker. (Meta doesn’t use it; most forums hosted by Discourse don’t use it.)

I think that if Discourse accepts my suggestion to begin sending “can’t reset password, your account doesn’t exist” emails to email addresses of accounts that don’t exist, it would make sense for the hCaptcha plugin to work on the password reset form as well as the sign up form. (I still wouldn’t need/use hCaptcha myself.)

3 Likes

Yep, that’s valid. I only thought about the case on its own, not considering other areas where it’s already possible and, as it happens, completely impractical to prevent.

Don’t they though?

  1. I forgot my password and I want access to this site. I enter what I think is the right email
  2. I don’t get a password reset link

So now I automatically know one of two options: One, I entered the wrong email or Two, the site isn’t working correctly.

My options are now: try another email, or try and contact someone who runs the site.

Now with your suggestion I get an email telling me the account doesn’t exist. My options are try another email, or contact someone who runs the site. It’s the same endpoint with 0 extra steps

1 Like

Except… the most of ordinary users don’t think that way, or at all.