On our forgot password reset form, is it ok to leak that a given e-mail address entered is invalid? Or should we always just return success and check your e-mail, even if the e-mail is not valid.

I feel like always returning success can provide a bad user experience, i.e. if a user is trying to remember which e-mail they used for the service.

5 Answers 5


I would not say that it is a bad experience to ask the user to check their email account - that would be the location where they will be expecting to go to next, regardless. If they are not signed up you could send them an email saying that their email address is not associated to any account. This would stop any other user from verifying whether the email address is registered with you or not (username enumeration).

Please also see my answer here: How to prevent email discovery in forms?, which could be relevant.

  • 1
    I like this suggestion. Every form I've seen so far that does not do e-mail validation on the form just says something like "If there is an account associated with that e-mail, you will receive a message from us...". This leaves your potentially checking your e-mail over and over again, wondering if the form actually worked, for a message that will never come if you entered a wrong address. So, the solution should be to say on the website "An e-mail has been sent to the provided address" and have the e-mail include validation of whether the address matched an account or not.
    – Iszi
    Jan 24, 2014 at 18:39
  • 2
    I understand your points but I disagree, a malicious user could easily use this in an effort to overload yours or anothers mail server, for example using small botnets to continually request reset emails to random addresses from multiple sites using this configuration.. It's effectively an amplification attack even if you only allow limited requests from same IP's. Jun 20, 2014 at 15:35
  • 1
    @user2867314: Those are solvable problems though - CAPTCHA or rate limiting based on IP, target email address or target email domain. Jun 20, 2014 at 15:38
  • CAPTCHA, yes agreed, anything else could leave to further problems, IP limiting can be trivially overcome with open proxies, target email domains can lead to DoS for any users wanting to reset on that domain, pulling down your password reset functionality. Not trying to be argumentative here, just saying. When solutions require cascading controls, in many cases a slight loss of usability may be preferable? Of course CAPTCHA may be in place elsewhere also, then great, go for it! Jun 20, 2014 at 15:45
  • @user2867314: I meant CAPTCHA on too many requests per ip, email or domain or just if abuse is detected in general. Rest of the time requests can come through without CAPTCHA. Jun 21, 2014 at 14:10

It is definitely an information disclosure issue. The question is whether its a big issue or not. Internal apps possibly not. Internet-facing maybe depending on what the app does. This is up to you or whomever/whatever you're protecting. This is also related to registration disclosure. If you try and sign up for an account with the same email etc.

My personal preference is to display a message along the lines of "We will email you a [whatever] if we have the email address on record".

  • I don't like this solution as it may leave a legitimate customer wondering if the form was broken, when they may have just used the wrong address on the form. A better solution would be, as suggested by @SilverLightFox, to always send an e-mail to the address provided on the form and have that e-mail include validation of whether the address matches an account (and, if it does, then include the next part of the password reset process).
    – Iszi
    Jan 24, 2014 at 18:46

Clearly the concern here is the possiblity of an attacker the enumerating email addresses of existing users by trying every possible combination and seeing what works, or possibly the risk of improperly disclosing the fact that a given address is associated with a user.

There's a few ways to do this, and the "forgot password" method is only one. Another is to attempt to enroll using someone else's email address and seeing if it's rejected. And depending on the application, there may be many other similar techniques.

The risk is very low, since the information you'd get is typically not very useful. Since all you get back is a "yes/no" answer (i.e. you don't get back their username or last known IP, for example), it would be difficult to leverage this knowledge in another attack. But perhaps not always impossible.

Still, in many applications I think it would be considered an acceptable risk for users in exchange for a bit of user-friendliness in your forgot-password screen assuming you take some reasonable precautions.

Of course, rate-limiting is going to be critical. You should be doing this already. If a person tries this more than a few times in a short while, you should make them slow down. And perhaps if they persist, you should make them stop and call you instead.

Another possibility is captcha -- they're not perfect, but they certainly make automation more difficult.

And another is requiring more information than just the email address. Perhaps they need to supply both their email address and their zip code or last name or favorite pokemon. Of course this opens up the slight possibility for abuse such that an attacker could use your service to link email addresses to favorite pokemons, but such an attack would probably be too costly to be worth their time, especially if you include the mitigation above.


A user-friendly login experience will ask for a username or email/mobile first and behave differently depending on whether a given user has an account on the site or not.

If your site supports usernames, they can be used as the login identifiers instead of email addresses or phone numbers. Users who don’t want others to know that their email address or mobile number signed up with site would register a username, and turn off the ability to login with an email address or mobile number.

Keep in mind as well that many sites have a “real names policy”, and people re-use their avatars across sites, so as long as you are pulling that info from eg Facebook, the user can be tracked across sites with some certainty by matching their name / avatar to the site you pulled it from.

Having said all that, as long as you’re not leaking the user ID / username to the browser, even over the wire (eg in JSON) the mere fact that someone verified a specific email or phone number doesn’t let an attacker do much more than know “the real Bill Gates uses this site”. Something that many people might already know due to blue checkmarks or whatever. If Bill Gates wanted to remain undercover, he should have used a different email address (or at least an email alias from google like [email protected] hoping the site doesn’t normalize email aliases).

I actually recommend for everyone to use different email aliases on every site to create accounts, in order to prevent a whole class of phishing attacks where the attacker actually social-engineers the site operators instead of you: https://www.wired.com/2012/08/apple-amazon-mat-honan-hacking/


I think that you should tell the user that his/her email is invalid, if you always say 'success' they will never know if the password reset is ok or not, and then, they will stop trying at the first attempt. Of course an attacker could use this to discover emails.

I think the best solution here is to make a reset password with 'Login' and 'Email Address'.

If the user puts Login or/and Email address wrong, you just display a message 'Incorrect Info , check Login/email'.

Don't tell if the Login or the Email is wrong, so you don't fall to the first security issue.

  • This assumes the login identifier is not the email address.
    – Steve
    Jan 22, 2014 at 20:03
  • We don't have username, your e-mail is your username.
    – Justin
    Jan 22, 2014 at 20:19
  • @Justin so that's different... Jan 22, 2014 at 20:54
  • This is a relatively trivial measure to bypass. If you have someone's e-mail address, you can quite probably easily find or guess the user names they would have selected. Then, just brute-force username/e-mail address combinations until you find the right one (or determine all invalid).
    – Iszi
    Jan 24, 2014 at 18:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .