Paid Advertising
web application security lab

Brute Force Password Guessing

Last night a webmaster for a pretty large website mentioned that he was having problems with people doing password guessing against known user lists. This is a really common problem in the web application security world. It’s trivial to mount large scale password guessing attacks against websites, and there’s very little you can do about it. First, let me explain the three different types of password guessing brute force attacks:

Vertical Veritcal password guessing is where you start with a single known userid and you throw thousands of passwords at the script, testing each one in succession. These are by far the easiest to detect because the way databases are set up, it’s trivial to set up a counter for the number of times a userid has been tested. Once it reaches a limit you ask the user to do something special (unlock an account or otherwise).

Horizontal Horizontal password guessing attacks use the same password but request many different usernames. This is much harder to detect for a few reasons. First, the password is staying the same but generally people don’t have a database of attempted passwords, and passwords aren’t unique anyway, so that wouldn’t help. Secondly, a table of guessed passwords per username is irrellevant, as they are only guessing one username password pair at a time, and the username changes. Thirdly and most importantly, you cannot seperate the guessing by IP address because of companies like AOL who use massive super proxies and route thousands of people through the same account.

Diagonal Diagonal password guessing is by far the hardest. Not only does the attacker shift the username, but they also shift the password on each guess. There is relatively no way to stop this type of user except banning their IP address or asking them to remedy in some way or another, which is easy enough to defeat by simply changing IP addresses. And if they come through an AOL proxy, you’re out of luck because then you are asking all of your AOL users to remedy who came through that proxy (which could be upwards of 30k users or more). That may or may not be a big deal depending on what the remedy is and how many AOL users you have.

There are certain things I don’t recommend. For instance what PassMark did to Bank of America. You don’t want to block your users outright when their password fails. This just sets up a situation where competitors can deny service to all your users simply by enumerating through them in the most obvious ways to get you to block the accounts.

One common way to get around this is to ask a user for a CAPTCHA as a remedy. Of course, that represents problems for accessability, but that can be mitigated as I have discussed in previous posts. Another way is to ask the user to limit their account by IP addresses. Give them a few days to tell you all the IP address ranges that they’ll be logging into (optionally) and let them limit access to their account. That way outliers from those IP ranges will set off alerts, or at minimum you don’t have to allow access, so the attacker will waste time.

However, you end up doing it, it really won’t stop a determined attacker, but it will make it so difficult it may be easier to attack other targets. “I don’t have to run faster than the bear, I just have to run faster than you.”

11 Responses to “Brute Force Password Guessing”

  1. David Kierznowski Says:

    RSnake mentioned some nice ideas to preventing these sort of attacks. In fact I would have “almost” recommended the same solutions.

    Although implementing a CAPTCHA system is effective it sometimes is not always the easiest for the company to implement. Denying by source IP can be a nightmare and certainly not the way to go in my opinion. Not to mention this wont protect users going through a proxy server.

    An account lockout facility is almost always supported by web frameworks and applications. We obviously cant have the lockout being permanent as this would deny services and cost the company heavily on time. However, if used correctly an account lockout facility can still be useful. The trick is to only lockout the account for a set period of time. I have recommended locking an account out after 3-5 attempts for a time period between 15-20 minutes. This will prevent overhead on the helpdesk and if you were to draw a graph based on user usage verse the blind brute force attack (mentioned in the article) you will see that the attack affects are drastically reduced if not completely.

    One final point on the CAPTCHA system. These are not always 100% secure either. Simple text representation of images can be converted back into text.

  2. pheno Says:

    Just use a captcha that can’t easily be back-converted to text, and force the users to choose strong passwords (or generate the passwords yourself and email them).

  3. Edward Z. Yang Says:

    Well, you could make it difficult to get a list of usernames to perform horizontal and diagonal attacks on. Email, for example.

  4. xandi Says:

    Isn’t this the perfect reason to push SSL user certificates? For applications like online banking I don’t quite see a reason not to do it.


  5. RSnake Says:

    Sure, if people can figure out how to use them. That’s pretty complicated compared to just saying “I’m on a machine I trust, make this IP address safe” It’s all the same limitations as IP address except now you can take your laptop anywhere. It doesn’t buy you that much in the grand scheme of things over IP address alone.

  6. head.hacker Says:

    We manage MILLIONS of users. Some users have the same IP for years, other have (legitimately) 20 different ones in a short time period. Trying to find one size to fit all is not even remotely possible. You can implement a tiered approach. Some ideas are:

    1) The front door SHOULD be well-locked with a unique username (NOT part of a real name), a forced hard to guess longer (8 char) password, and a CAPTCHA or PHOTO or OTHER customization option. These should be separate steps in the process. However, in all this you still trust the COMPUTER doing the transaction. Yes, a cert here helps but not if the problem is in your network or they are in your house.

    2) After login, you must get more personal to do more business. Just like entering a secure facility, you may need a code to park, a badge to get into your area, then enter a password/key for a secure area, and finally a physical security scan for the most secure parts. So now you ask for even more details. Favorite colors, past cars, or even better, things that are NOT generally featured on personal websites or can be googled (color of PAINT in bathroom?) are good starts. Ask a few custom questions, get a few custom answers and pick a few at random.

    3) Now if you insist on actual transactions, not just viewing (or you need more rights in a DB, for example) now we reach out. Maybe ask for an alternate channel of communications, like a cell-phone (pre-defined numbers only) or secure alternate email or other out-of-band solution.

    Also, for high-value logins, you can insist on hardware tokens, and other such means that consist of true multi-factor authentication. That would be something you have (token/card/FOB), something you know(user/password), and something you are(biometrics).

    As a final note, NONE of these are foolproof, they merely raise the bar in increments, decreasing the odds of an imposter gaining access. The simplest way to prevent brute forcing? Multi-page logins w/ required waits combined w/ captchas are my favorites. Don’t forget to display the BYTE same page, and access the same logic tree whether or not the username and/or password are valid as well.

  7. Krk41 Says:

    Can we use a strategy which combines the CAPTCHA and account lockout strategy, like:

    A) The application allow users to provide incorrect password 3 times
    B) After that it introduces a CAPTCHA for the next 3 times (considering that the user has actually forgotten his password and no tool is trying to brute force)
    C) After these 6 attempts, lock the user for 15-20 minutes and then unlock automatically OR support desk intervention maybe required for critical applications like banking applications etc…

    Ofcourse the application must implement a strong password policy.

  8. RSnake Says:

    Krk41, that’s not a horrible idea, but the problem is that still allows the bad guys to run brute force attacks, they just have to do them slowly. I’m assuming your timeout is 15-20 minutes based on username (if that’s not right, feel free to correct me) because if it were based on IP address you’d be locking out AOL almost instantly if you have any volume of user traffic. So all they need to do is guess three times for a username then switch to a new username and so on until 10-15 minutes is up and then they can cycle back to the original username since the period is over.

    I’ve actually seen attackers do this sort of activity (wait for timeouts to be complete before testing again).

  9. enisk Says:

    Well, in all the cases
    we should have a security guy analyzing the logs or a web application firewall, don’t we?
    (assuming application is logging these attempts or a web server/reverse-proxy with mod_security, mod_evasive is waiting before web application)

    I assume even a 5 minute lock will slow down the hacker.
    Well, we sure can’t run faster then a determined bear, can we?

  10. krk41 Says:

    RSnake, I see what you are trying to point out. But then we also have to leave some pathways for the legitimate users to interact with the application, in case they have forgotten or wrongly typed a password.

    But yes, as you have rightly said - whatever we do, it really won’t stop a determined attacker, but it will make it so difficult that may be it would be easier for him to attack other targets or maybe prompt him to look at other weak links.

  11. RSnake Says:

    I think we are saying the same thing. Yes, it’s vital for allowing users the ability to log in even after making a mistake and not to block users based on other people DoSing their account with failed login attempts. But that same loophole allows the attacker to do the same.

    It’s sorta a no-win situation.