Forgot password and revealing whether account exists

Question

So when you hit that forgot password link and enter your email address, it seems that sites (and other programmers I've spoken to) are one of either two mindsets;

• Notify the user whether or not the email address matched with one in the database and based on this advise whether a reset password email was set or;
• Immediately respond with a "Email sent" or "If this user exists, we have sent you a password reset email" regardless of whether or a match occurred resulting in an email sent. This is done (apparently) for security reasons.

I've implemented the latter myself and generally found it raised annoyance with users due to;

1. If a user mistypes their email address, they are told an email is sent, but they will never receive one.
2. If they've typed in a different email address than the one they registered with, again they won't be getting an email.
3. A combination of the above can result in multiple attempts but no receipt of a password reset email, resulting in giving up.

Finally, upon investigation of popular websites that use the second scenario, I've found that attempting to register an account with these sites where the entered email address matches an existing account, a "this email address is already in use, or unavailable" type message is displayed anyway.

As such, what are the benefits not revealing whether a password reset email has matched an account, and, how are these beneficial when registration requires email matches to be revealed?

Answer 1

There is sometimes a trade-off between security and usability.

If it's important to you or your users that other people don't know they're using the site, then your second choice is the best one.

You can always send an email to an address that doesn't exist in your system, like "Someone requested a password reset for this address, but it's not in our system". That handles your second complaint.

Add a link to re-do the password reset on the confirmation page. Hopefully, they'll type in the email correctly the next time.

So, decide whether avoiding user enumeration is more important than the occasional mis-typed email address.

What are the benefits not revealing whether a password reset email has matched an account

You don't give or confirm a list of users' email addresses to an attacker and don't let other people know that a given user is using your site. If it's a site about kittens, who cares? If it's a bank or extra-marital affair site, then this is important.

How are these beneficial when registration requires email matches to be revealed?

Who says registration requires this? Do the same thing for registration. Request email address, send "step 2" link, or "someone requested a registration on our site but this address is already registered" emails.

Answer 2

The answers so far are good but it's important to note that from a profiling point of view- I don't care if I don't get in to their account but the knowledge they're using a service is enough to social engineer a situation/monitor their social feeds for potential passwords (pets, kids, cars etc).

That being said, during user signup it would be a bad UX move (or at least a minefield) to explain to the user the email address may or may not already be in use. You could come up with some funky logic that lets them recreate an account and emails them saying "hey, looks like you already have an account" but that's clunky and frankly a waste of time for the user. Same goes with a login page- "invalid user/pass" for either with account or without an account is a good habit... but when the registration page gives that information freely AND you run the risk of users being annoyed if they think they've signed up but haven't.

Personally, I try and go for OpenID as much as possible for web based services to prevent this scenario from even occurring. We all have a Google/Facebook/Twitter account these days...

Answer 3

So I guess as a primer we need to consider what an attacker can actually do if you confirm / deny existence of an email on your system in some easily accessible way. This is a possible scenario:

• An attacker has gained access to a database of compromised email addresses + passwords. (i.e. they can log into any of these user's emails)
• They want to gain access to some of your user's accounts on your service.
• Your service will confirm or deny whether an account exists with an email address.

In this case they can simple try all of the emails that they have in their database against your password reset function, gather up the returned results and if you confirmed that any of them exist, log into those emails and follow the password reset link.

If it's easy enough to follow the sign up process, then you're correct in assuming that the password reset being opaque gives no added security. They can simple perform the aforementioned attack on the sign up page instead of the password reset page.

Some ways I can think of to mitigate this are:

• Force users either to sign up with a username or assign them a username when they register, and get them to use that from then on rather than their email address.
• Don't allow them to log in until they've clicked the email confirmation. That way, if someone tries to sign up with an email that's already been registered, simply say "we've sent a confirmation email to your email address, click it to log in"
• Attempt to implement some kind of anti brute force methods on pages that can confirm / deny existence of an email address, such as a CAPTCHA.

However as previously stated, both of these relatively significantly impact usability. As always, security is always a trade off between practicality and paranoia.