The Secure Web Series, Part 2: How to Avoid User Account Harvesting

Screen Shot 2014-02-23 at 8.50.33 PM.png 

Welcome to the second post in a series on how to avoid common web application vulnerabilities, called The Secure Web Series.

 
In 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.
 
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 the first post of the series we talked about Building a Secure Password Reset Mechanism, and in this installment we will cover Account Harvesting

 

Avoiding Account Harvesting
 
Here at Fortify on Demand we see many variations of information leakage within web applications. Here we'll focus on three flaws that combine to form the trifecta of Account Harvesting.
 

1. User Enumeration: The ability to programmatically determine whether a given account is valid on a system—usually without restriction, i.e. without anti-automation getting in your way

 

2. Weak Password Policy: The lack of a policy and/or the presence of a weak policy, e.g. the ability to create extremely short passwords, passwords based on common words, etc.—basically anything that lends itself to being guessed using wordlists

 

3. Lack of Account Lockout: The failure to lock out an account after a certain number (3-5 usually) of failed account login


User Enumeration

 

User enumeration enables attackers to compile a list of valid users on your site. Once this is done they can then perform an authentication attack using a quality list of passwords. On the security side we use lists like those maintained in our Seclists project.

 
Remediation
 
Preventing against user enumeration can be done a number of ways, including:
 
  • CAPTCHA defense
  • Rate limiting within the application
  • Blacklisting based on source IP after a certain number of attempts
  • Blacklisting based on cookie after a certain number of attempts
  • Blacklisting based on other user characteristics after a certain number of attempts
  • A combination of these *

Weak Password Policy

 

password-policy.png

 

Having a weak password policy makes the ability to gather a user list infinitely worse. If the password policy is strong then it's not likely that a few guesses by an attacker will yield results. But with a weak policy hitting the top 100 passwords for any given (know to be valid) account may very well get you in.

 
Remediation
 
The frustrating part of seeing this vulnerability in websites is that password policy is a well-known security layer in other disciplines of information security. Within operating system and network security it's been accepted for years that poor password policies lead to compromise, but many web developers have yet to receive the message.
 
The simplest fix for this issue is to use a well-known password complexity library for your platform. Be sure to tune it properly for the security level of your website, e.g. it's probably sub-optimal to require a 14-character alphanumeric password on a marketing site with nothing sensitive on it.
 

Lack of Account Lockout

 

put-password-outlook-2007-800x800.jpg

 

The final piece that makes the other two issues so terrifically horrible is not having a lockout policy. If you were able to get a list of users, and the password policy was relatively weak, but you locked out accounts after a few bad guesses, things wouldn't be so bad.

 

But there's real trouble if you have all three.

 

Then you can just keep guessing with your password list on each and every account, and your chances of getting into at least one go up dramatically.

 
Remediation
 
Like the password policy issue, the fix here is simple--lock out accounts after a certain number of failed login attempts.
 
The Trifecta

 

By themselves each of these vulnerabilities is serious, but they are nowhere near as bad as when they combine together. If you have user enumeration and weak password policy, but you lock people out after a few attempts, then the opportunity for attack is severely reduced (you basically go with your best list of n-1 passwords and hit each valid account with it).

 

Similarly, if you have user enumeration and a lack of account lockout, but you have a requirement for complex, 10 character passwords, then your opportunity may be reduced as well. You may have issues with how quickly you can query the web server, you may be detected by the target’s security team, etc.

 

But if you have all three, well, you’re about to have logins to the app—it’s that simple. Factor in the reality that some are likely to be higher privilege accounts, and that there’s likely to be password sharing going on, and you see the reason that pulling a list of a few thousand valid accounts off a system is a major score for attackers.

 

Best Practices Review

 

Ideally you wouldn’t have any of these issues with your web properties.  If you are in charge of securing your sites you should be particularly keen to avoid having all three of these. Here are a couple of tips:

 

  • Employ anti-automation on user validity checking. Even if you do have a system for checking user account validity, there’s no reason for someone to do so more than a few times. If there is, built a separate service for that and protect it uniquely.

  • Remember there’s a reason for your password policy. It’s not just for show, or to check a box. It’s because it actually does make it (somewhat) harder for attackers. And in a game where we’re often just raising the cost of a successful attack against us to compel someone to pass us over—that’s a win.

  • Monitor your site for failed application logins. Remember that prevention is ideal, but detection is a must. Someone trying to bang down the front door is something you should know about, as it may mean they’re coming around back next.
 
Conclusion
 
Keep in mind this isn’t a complete guide to security issues related to authenitcation issues and account harvesting, 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 Cross-site Request Forgery.
 
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

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.