10

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.

Justin
  • 1,117
  • 3
  • 14
  • 20

4 Answers4

8

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.

Community
  • 1
SilverlightFox
  • 33,408
  • 6
  • 67
  • 178
  • 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 '14 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. – user2867314 Jun 20 '14 at 15:35
  • @user2867314: Those are solvable problems though - CAPTCHA or rate limiting based on IP, target email address or target email domain. – SilverlightFox Jun 20 '14 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! – user2867314 Jun 20 '14 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. – SilverlightFox Jun 21 '14 at 14:10
1

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".

Steve
  • 15,155
  • 3
  • 37
  • 66
  • 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 '14 at 18:46
1

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.

tylerl
  • 82,225
  • 25
  • 148
  • 226
-1

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.

Stephenloky
  • 383
  • 1
  • 4
  • 16
  • This assumes the login identifier is not the email address. – Steve Jan 22 '14 at 20:03
  • We don't have username, your e-mail is your username. – Justin Jan 22 '14 at 20:19
  • @Justin so that's different... – Stephenloky Jan 22 '14 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 '14 at 18:43