I am building a new MVC app.
Considering this "forgot password" flow:

1)You enter an email.
2)You press "send recovery password".
3)An email awaits in the inbox, pressing the link in it brings you to "new password" screen.

In phase 1, there is no limitations on the email you provide. (It may not even exist).

Are there any major security flaws with this flow?

  • So entering a non-registered email address would create an account for them automatically? It's sort of odd and you may want to consider whether users understand what is going on. Also, I could send lots of emails with useless links to people that never signed up for your website. Then again, you can do that with most register forms, but it's something to think about. – Luc Oct 15 '14 at 22:52

Possibly. It's not immediately clear if you are relying on the email address as the sole identifier (i.e. you're using it as the username) or if a separate username is in play. If the latter case, then the obvious flaw is that an attacker can supply the username of someone else, but provide their own email address as the destination for the recovery password.

Assuming the email address is the only identifier for a user, obviously it will need to be supplied by them in order to reset their password. I would suggest that regardless of whether an account associated with that email address actually exists, the system should respond similarly. (E.g. saying "Your password recovery information has been sent.") However, you would obviously only want to send the recovery email if there is a corresponding account; if no such account exists there is nothing to recover. This prevents an attacker from trying multiple addresses to see which succeed and which fail, and thus building a list of valid accounts on the system. (If your application is faster to respond if it doesn't need to send the email, you may wish to intentionally add a random bit of time delay to hide that.)


There are some potential significant issues, mostly related to aspects of your procedure that have not been specified (hence "potential"). These are additional considerations, rather than problems with your method:

  • Automated bots might spam users by submitting lots of different email addresses. Emailing (or at least giving the same form response), regardless of whether a user is valid or not, is a good way of preventing username enumeration, but it does open you up to this risk. Consider using a CAPTCHA when users are requesting the reset email, to prevent automatic submission.

  • The secret value embedded in the link might be too easy to guess. If the token included in the link is not randomly generated with a high level of entropy, an attacker might be able to guess it.

  • The secret value could be re-used by an attacker if the email is compromised at a later date. The token should be single-use (i.e. a nonce), and ideally expire after a set amount of time (appropriate for your user base and security requirement - OWASP recommend as little as 20 minutes here, but you may consider your application to not be that sensitive).

  • The secret value could be intercepted. Email lacks end-to-end encryption, and you do not know how secure a user's endpoint or mail servers are. Some applications therefore require additional verification steps before or after sending and following the link. OWASP recommend secret questions in addition to the email, although you may feel that this is excessive for the sensitivity of your application.

  • The new password is not submitted with transport security. Naturally the URL in your email should point to an HTTPS page (partially so the user can verify that they are submitting their new password directly to the server), and then the form should submit the password over HTTPS as well.

  • An attacker requests a reset email on a user's behalf, and the user is unable to prevent the token from remaining active. Consider providing a way for users to cancel the password reset from the email, enabling them to deactivate the link if they did not request it.

  • The user is not notified if an attacker succeeds in changing their password. Consider at least notifying the user via email of every successful password reset, in case it was not initiated by them.


I think it's important to check that entered email addresses actually belong to one of your users before you send the recovery email. Assuming that your sign-up form already collects email addresses, it would be silly not to make use of them to perform this simple check.

Without verification, one major concern would be spammers/hackers entering tons of made-up, invalid email addresses. This would cause your server to send many messages that bounce, and draw attention from spam filters and spammer databases. Eventually, your server could get blacklisted, and no emails from your site would go through anymore.

Plus, mistyped email addresses are quite common, so you could have instances where a user accidentally sends a recovery email to someone else's inbox.

Without additional information about your implementation I can't really point out any other issues, but in phase 3, there are some additional security measures you can consider. For example, you need to make sure that the recovery URLs are long and random, so that they cannot easily be guessed or brute-forced. You also probably don't want the URLs to be active forever; it's a good idea to expire them after an hour or two if a user generates a recovery URL but never actually visits it, or if the user visits it but never provides a new password. To further reduce the chance of a hack, you can completely disable the password recovery feature if the account was used within the past few days, or if the IP-based location is atypical for that user (though these measures may inconvenience users).



Spammers could spoof your password reset email and trick other users to click on a link that phish for information

Attackers could DDOS your server

By submitting the form rapidly, your server might not be able to keep up with the processing power required for sending out emails fast enough

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.