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

Screen Shot 2014-02-09 at 12.37.04 PM.png

 

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
 
Screen Shot 2014-02-09 at 12.58.11 PM.png
 
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.
 
Remediation
 
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
 
Screen Shot 2014-02-09 at 1.04.20 PM.png
 
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
  2. HOW DID THEY HAVE MY CLEARTEXT PASSWORD?
Bad on top of bad.
 
Remediation
 
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
 
Screen Shot 2014-02-09 at 5.36.18 PM.png
 
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.
 
Remediation
 
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.
 
Remediation
 
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
 
Screen Shot 2014-02-09 at 6.05.33 PM.png
 
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.
 
Remediation
 
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
 
Conclusion
 
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@hp.com).
 
 
: :
 
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 daniel.miessler@hp.com and on Twitter at @danielmiessler

Comments
mobile application development(anon) | ‎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.

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
http://www.danielmiessler.com/about
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.