670887 - create account provides too much information to potential malicious users

Status: REOPENED

(Bugzilla :: User Accounts, enhancement)

Description

[Raymond Forbes[:rforbes]]

issue:
-------
when a user attempts to create an account an email is sent.  This email is different depending on if the email address has been used or not.  If it has, the email says "this email is already in use".  This could give useful information to an attacker in order to brute for accounts.

recommended remediation
-----------------------
use generic messages in email. 

Example: "Instructions regarding registering an account have been sent to your email address."

Comment 1

[Raymond Forbes[:rforbes]]

This is also true for change password token.  

The following message is returned when an email that is not taken is submitted:

"A confirmation email has been sent containing a link to continue creating an account. The link will expire if an account is not created within 3 days."

An email that is taken responds the following message:

"There is already an account with the login name [e-mail]."

solution is to utilize a generic message whether or not the email address is taken or not.

Example: "Instructions regarding registering an account have been sent to your email address."

Comment 2

[Gervase Markham [:gerv]]

This should probably go upstream.

The message should avoid lying. So:

"If there is not already an account for this email address, instructions on how to complete registration have been emailed to you. A reply must be received within 3 days.

If this address is already associated with an account, then no action has been taken."

Gerv

Comment 3

[Frédéric Buclin]

This is not a security bug. When you register your email address, you have to know if it's already used in this Bugzilla installation or not. It doesn't make *any* sense to hide this information. The user doesn't need this "trick" to "brute force" user accounts. Using his own user account, he can already type random names in e.g. the CC list of bugs, and see lists being displayed there. No mystery here. And brute force won't work. The attacker will be locked at his 5th attempt.

Comment 4

[Reed Loden [:reed]]

It's not a "security bug", yes, but it is a common security enhancement.

Note that another way that somebody can do this is to use the "forgotten password" functionality, which is very helpful at telling whether or not an account exists or not.

Example:

Enter "[e-mail]" in forgotten password.
Get back "There is no user named '[e-mail]'. Either you mis-typed the name or that user has not yet registered for a Bugzilla account."

While LpSolit is true that there are many other ways to enumerate Bugzilla's user database, I think this becomes more of a problem for private Bugzilla databases that don't allow just anybody to register. These "tells" can give an attacker very useful information about that Bugzilla instance that he/she may not be able to get via the other normal means.

Reopening this and converting it to an enhancement request. Leaving it open as non-security, however, as there's nothing sensitive here.

Comment 5

[Dave Miller [:justdave]]

If the user tries to sign up for an account with an email that already exists, we should treat it as a password reset request instead.  Don't show anything different in the UI, just the email they get would tell them they already have an account and here's a link to reset your password.

The ambiguous action here would be if the user has already requested a new account but hasn't responded to the token email yet.  We can't reset a password on an account that doesn't exist yet, and sending them additional email to say "you already tried to sign up, here's your confirmation token again" could possibly lead to a mailbombing if not done carefully.

Comment 6

[Max Kanat-Alexander]

(In reply to Dave Miller [:justdave] from comment #5)
> If the user tries to sign up for an account with an email that already
> exists, we should treat it as a password reset request instead.

  No, I disagree, because the user's intention wasn't to do a password reset. It was to sign up for a new account. If the system isn't going to carry out their intention, it should tell them. I think this is even more relevant for Bugzilla instances that have non-email usernames in addition to their email usernames.

Comment 7

[Dave Miller [:justdave]]

(In reply to Max Kanat-Alexander from comment #6)
> (In reply to Dave Miller [:justdave] from comment #5)
> > If the user tries to sign up for an account with an email that already
> > exists, we should treat it as a password reset request instead.
> 
>   No, I disagree, because the user's intention wasn't to do a password
> reset. It was to sign up for a new account. If the system isn't going to
> carry out their intention, it should tell them. I think this is even more
> relevant for Bugzilla instances that have non-email usernames in addition to
> their email usernames.

In that case, we tell them they already have an account and instruct them to use the password reset facility if they don't remember the password.  But it would be more user-friendly to send them a reset link and say "just don't use this if you remember the password"

Comment 8

[Frédéric Buclin]

(In reply to Dave Miller [:justdave] from comment #5)
> If the user tries to sign up for an account with an email that already
> exists, we should treat it as a password reset request instead.  Don't show
> anything different in the UI, just the email they get would tell them they
> already have an account and here's a link to reset your password.

This would be a great way to spam existing accounts, anonymously.

Comment 9

[Dave Miller [:justdave]]

(In reply to Frédéric Buclin from comment #8)
> This would be a great way to spam existing accounts, anonymously.

So is the existing method for resetting passwords, but we still do that.  How is this any different?

Comment 10

[Matt Fuller :mfuller]

I am working on resolving a number of Whitehat bugs and this is the oldest one that is not yet resolved. Does anyone have an update on this?

Note: changing all of our messages to generic ones will prevent 95% of these issues. For example in the reset password page, instead of saying "email [e-mail] does not exist", the message should read "A reset email has been sent to your email" even if the email doesn't exist.

Comment 11

[Matt Fuller :mfuller]

Ping for an update here.

Comment 14

[:Atoll]

Hi Emma, I'm trying to determine if this bug is something we intend to fix, or if it can be closed wontfix. Are you the right person to ask for that determination? If not, can you help me find the right person? It's the only remaining open bug blocking the parent bug from several years ago being closed, which usually implies "wontfix". But just in case no one's looked at it in some time, needinfo requested.

Comment 15

[Mark Côté [:mcote]]

Note that this bug is filed in the Bugzilla product, meaning the generic software application used by orgs around the world.  If we want to implement this specifically for Mozilla's installation, bugzilla.mozilla.org, a separate bug should be filed under that product.

Comment 16

[:Atoll]

I don't have any opinion on whether this should or should not be fixed for either upstream Bugzilla or only BMO, but if you can help ensure that it's evaluated for inclusion or rejection for upstream Bugzilla, I'm sure that would strongly guide any BMO decision.

Comment 17

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

I'm going to move the bug into BMO for now, and get a couple of questions answered so I can prioritize it. If we decide to take it in BMO, then Bugzilla can take our fix.

Comment 18

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

Since it is blocking and dependent on other bugs, I'm going to have to clone into BMO instead.

Comment 19

[:Atoll]

I closed the upstream meta-bug as this was the only one left attached to it. Since this isn't actionable until the BMO bug is evaluated, temporarily closing WONTFIX to clear out the dependency chain on this ancient security metabug. Anyone is welcome to reopen it when desired.