Protect Your Assets
Showing results for 
Search instead for 
Do you mean 

The Secure Web Series, Part 1: Securing Your Password Reset Mechanism

danielmiessler ‎02-09-2014 06:16 PM - edited ‎07-07-2015 12:38 PM


Welcome to a new series on how to avoid common web application vulnerabilities, called The Secure Web SeriesIn this series of posts, I’ll be exploring some of the most common vulnerabilities we see in our testing practice here at Fortify on Demand
The focus of the series will be on vulnerabilities that aren’t easily identified via automation, as these are harder to find using readily available tools and many testing offerings tend to miss them during assessments. The target audience is web developers and web application security testers.
In each installment of the series we’ll cover the following areas:
  • The most common flaws we see in the real world for this particular component of web applications
  • How to avoid making each of those mistakes
  • A list of best practices for that component

In this first installment, we'll be tallking about vulnerabilities in the Password Reset Mechanism


The Insecure Password Reset Mechanism
Unfortunately, there are a myriad of ways to do password resets insecurely:
  1. User account leakage
  2. Sending the real password in email
  3. Predictable reset tokens
  4. Failure to expire reset tokens
  5. Auto-logon after reset
User Account Leakage

Injection attacks are noisy, take a long time, and have a decently high chance of getting noticed. So one of the first things an attacker (or a good security tester) will do on a site is look for a way to log in with a legitimate account. 
Many websites have a form field like the one above on their password reset page. Looks harmless enough, but most have an error in it: When you enter a valid email address it gives you one message (you’ll get an email shortly), and if you give it an email address that’s not in the system it gives you another message (email address not found).
This means that an attacker can use automation to guess email accounts, and come up with a list of valid users. From there you can throw some quality password lists at it and probably walk right through the front door with a valid account.
The way to fix this is to make the response to both situations identical (and that includes the time it takes to come back with an answer). So instead of saying, yes or no depending on the input, instead you ALWAYS say,
            "If your account was found, you’ll receive an email shortly."
That way we're not saying whether or not it was found, only that if it was they'll get an email soon.
Sending Your Actual Password in Email
One of the worst vulnerabilities we see in applications’ password reset systems is when the system just sends us our password in email.
There are a couple of problems with this:
  1. They just sent my password over the internet with no encryption
Bad on top of bad.
Avoid sending users their passwords, and instead have them come to the website and create a new one. And if you absolutely MUST send someone a password, it should be a temporary one that requires a reset when they log in.
You should never even know what a user’s real password is, let alone send it to them over the Internet without encryption. 
Predictable Reset Tokens

Another serious problem we often see with passwod reset systems is the use of predictable reset tokens. This happens when developers either come up with their own, or use someone else's homegrown solution for making the tokens.
Predictable tokens allow an attacker to make a large number of requests to the password reset function, gather a large number of tokens, and then analyze them for patterns. Once a pattern is found, the attacker can then infer the next tokens to come from the system and reset victims' passwords using those token links.
Use a modern framework's implementation of token generation. Never build your own.
Failure to Expire Reset Tokens
Once a password reset token has been used it needs to be rendered inactive within the system. We often find web applications here at FoD that allow the user (or anyone with the link) to continue resetting the password after it's already been reset once.
This is especially true because reset tokens are usually sent via email, which often traverses the Internet unencrypted.
For high security websites you should consider an additional security measure: Notifying the user if someone attempts to reuse the token. This can alert the user to a potential compromise of their email account or some other type of compromise of their security. 
Finally, if the password reset token is not used within a certain amount of time it should expire. This period of time should depend on the security level of the website, but between 10 and 90 minutes is fairly common.
Ensure that reset tokens are rendered invalid as soon as they are used, and for high security sites consider alerting the user and possibly the security administation team if there is an attempt to reuse one. Expire tokens that are not used.
Auto-logon After Reset

Finally, after the user has successfully reset her password, ensure that she's forced to return to the standard login screen and authenticate with the new credentials.
We see many implementations that, upon the user completing their reset, simply drop the user right into an authenticated session. This provides additional surface area for attack of your authentication system (via logic attacks errors and other methods) and should be avoided.
Another reason to avoid this is that all logins (attempted and successful) to your application should be logged, and a backdoor into the app (without going through the primary auth page) could leave a blind spot in your audit logs.
Ensure that all users are required to use the primary authentication page after resetting their credentials. Don't allow any backdoor entry through the password reset mechanism.
Best Practices Review
Ok, so let's hit the main points again all in one place:
  • Use cryptographically strong password reset tokens
  • Expire those tokens after a successful use
  • Expire tokens after 10-90 minutes--depending on the security of the site
  • Always reset the password on the website itself rather than emailing the user a new one
  • Ensure you use HTTPS on the page where you have users reset their passwords
  • Detect (and potentially respond to) attempts to reuse reset token
  • Force the user to explicitly log in via the standard mechanism using their new credentials after the password reset process has completed
Keep in mind this isn’t a complete guide to security issues related to password reset mechanisms, but it should get you thinking about some of the main errors to avoid.
Also be sure to come back for the next installment where we'll cover Authentication Vulnerabilities.
As always, feel free to reach out with any questions via Twitter (@danielmiessler) or via email (
: :
Daniel Miessler is a Practice Principal with Fortify on Demand based out of San Francisco, California. His areas of expertise are web and mobile application security testing and building application security programs for the Global and Fortune 100. He can be reached at and on Twitter at @danielmiessler

0 Kudos
About the Author


mobile application development
on ‎04-09-2014 06:26 AM

Interesting topic shown here, i am now working on it regularly here and would say keep the future posts like this continusoly.

Web Application Performance Testing
on ‎11-14-2014 01:57 AM

Really a very intresting topic, This is major problem which most of the people are facing these tricks are really protected I will defintly like to apply thanks for saving us.

27 Feb - 2 March 2017
Barcelona | Fira Gran Via
Mobile World Congress 2017
Hewlett Packard Enterprise at Mobile World Congress 2017, Barcelona | Fira Gran Via Location: Hall 3, Booth 3E11
Read more
Each Month in 2017
Software Expert Days - 2017
Join us online to talk directly with our Software experts during online Expert Days. Find information here about past, current, and upcoming Expert Da...
Read more
View all