Password reset giving clues of possible valid email addresses

Question

We have a system where if you forgot your password and want to reset it, to go to the forgot password page and enter your email address. A temporary link will be sent to your email to reset your password.

Now, when we subjected our app to penetration testing, an issue was found:

Application is giving clues of possible valid email addresses when attempting to reset password. This functionality can be abused by simply guessing possible email address and being able to find valid ones through the error messages.

Well, there's only one field and of course its obvious that if a reset password attempt fails, it's due to an invalid email. Seems this penetration test is wrong. Are there any solutions to fix this issue besides adding an additional field (besides email) for password reset?

Answer 1

Don't indicate that the attempt "failed". A user (legitimate or otherwise), asks for a password reset link, and gives you an email address. All you should say here is along the lines of

Your submissions has been received. If we have an account matching your email address, you will receive an email with a link to reset your password.

The user will still get the link (success), but attackers won't know whether a provided email address is associated with an account.

Answer 2

The reason for this finding is that a user gets different responses, depending on the existence of the email address. This can be as simple as telling them that the address is not known, or something more subtle in the response.

The easiest implementation to avoid this kind of problem is giving back the exact same response, no matter whether the email address exists or not. A simple

The information to reset the password has been sent to the provided email address. If you do not receive an email, please check that you have supplied to correct address.

would do the trick.

If the email address is known to you, send the password reset information. If it doesn’t exist, don’t do anything. A real user will get the link, while an attacker cannot determine whether an email was sent or not.

Answer 3

What are we protecting against?

First of all one should ask what they are protecting against exactly. In this case there are two different threats:

• Threat 1 An attacker brute forces random emails to find valid registered emails. This could be theoretically used to create spam lists, but as far as I know has never been done as it's simpler to just sent the emails than go through the extra trouble (The number of time that I have receive spam mail claiming my [some US bank] account needed action despite not living in the US is countless).
• Threat 2 An attacker is targeting a specific user or a list of specific users. This is especially important when the bare fact someone is registered somewhere can have consequences. Example: The very act of having an account on Grindr or Ashley Madison can be dangerous in certain communities.

The bigger picture

The next question to think about is what other places might expose the same information and considering those as a whole. Typically the registration form will inform the user if the entered email is already registered, but this of course doesn't apply to most B2B software. Beyond that 'share with user' features (an input box where an email can be entered to share some object with this user) will often also expose this information, but as those are rare I won't include those in this answer.

Solutions for a system with public registration

First of all it's good to acknowledge to not informing the user that an account already exists during the registration process is from an UX perspective very unpleasant. The same applies to password reset forms that silently fail¹ when the user makes a typo or has multiple emails. This doesn't mean it's something one shouldn't do, but one should weigh it against the security risks and benefits.

Given a system with public registration the important thing to consider is how big Threat 2 is to the users of your product. Given even a modest risk it can be prudent to change the registration form to start with only entering a name and email, giving a message "check your email to continue sign up", and if the email is already registered sending the user an email informing them of this. Similarly in that case the password reset form will not inform the user in any way whether the email is valid.

On the other hand if Threat 2 is minimal we have to model exclusively against Threat 1. Of course the previous approach will also function perfectly against Threat 1 exclusively, but considering the UX cost it's worth considering other solutions. The most obvious solution is rate limiting² on both the 'email exists check' and 'password forgotten' checks (technically those calls can even go to the same API endpoint). These will often be designed to be fairly lenient for the first 10 calls or so, but get very limited very quickly after that point.

Important: Never remove error messages from the password registration without also implementing similar restrictions on the registration form.

Solutions for a system without public registration

It all boils down to the same issues as above (and I should have written this first), but without the 'extra' cost of the hit to the registration UX it's relatively 'cheaper' to have a secure password forgotten form, although of course it's still unpleasant for users and you still can consider whether rate limiting isn't enough for your specific threat model.

Notes

^{1: Instead of silently failing it's wise to at least sent an email to the entered email informing them that their email wasn't found. This 1) demotivates attackers from mass abusing the system (as it will be noticed) and 2) prevents users from wondering why they aren't getting an email.}

^{2: Do note that rate limiting can negatively affect users of large networks or VPNs. Always consider how important that audience is to you and based on that spend an adequate amount of time to ensure the application stays functional even when rate limiting is harshest (e.g. by lowering the rate limit by solving a captcha or setting the maximum rate limit to around once per minute and ensuring the application will wait the full minute (note: still will be unpleasant given a team of users signing up for the same service at the start of the same meeting)).}

Answer 4

As an addition to the answers above (Would be better suited as a comment but can't do that yet) another step the hacker can take is to measure the TIME of your response to the form. It might take you 10ms to determine the email doesn't exists, while it takes you 100ms to generate a reset link and send an email. The hacker can know if the response is slower that its a successful find. You can employ a random sleep timer in cases where the email is not found so that both responses take the same amount of time.

Answer 5

You should weigh up the problem versus the inconvenience of solution. It's often a tradeoff.

In my opinion it is usually better to sacrifice this bit of security for the sake of user experience unless someone might get persecuted for being registered in your site.

From time to time I come years later to a site and try to find which email did I use for the particular site. The sites that hide this information are quite annoying.

Answer 6

Note that this also (besides the other answers) applies to the registration screen, instead of complaining about already registered user sent them an email that they are already registered and provide no feedback about this in the web app besides "check your mail".

This is best done if you ask for minimum input on the first step before the email validation (which is also good for GDPR, where you can prove that the user got your info email and continued to register).

In fact it's no hassle on registration and should always be done. For reset password function we provide an option in the software where you can select direct feedback or email feedback. (In corporate scenarios, especially on the Intranet guessing emails is not a real threat).