Brute-force countermeasures

Password brute-forcing refers to trying all password permutations until the attacker finds the right one. Here are some of the most common ways to mitigate that risk:

  • Increase the length of the password.
    With every additional character, the number of permutations goes up exponentially. Say you use 26 letters and 7 characters. You’ll get 8 billion combinations. Increase that to 8 characters and you get about 200 billion.
  • Increase the number of possible characters.
    With 26 letters, both uppercase and lowercase, numbers and symbols, you get to 94 possibilities. This translates into 6 quadrillion possibilities for the 8-character password.

The human factor should not be ignored here. People often use letters in the beginning and numbers at the end. Many people also use common combinations such as “password”, “123456″ and “admin”. Attackers have a dictionary of these common passwords and can break many of those in less than a second.

Although it’s good practice to force users to use more than just letters, some websites are overdoing it by forcing users to enter at least one number, uppercase, lowercase, punctuation, symbol, etc. This can lead to very poor user experience, especially if you don’t tell them the password requirements before validating the form.

  • Requiring a captcha after a number of unsuccessful attempts.
    A user may make a legitimate error, but after 3 or 4 attempts, it becomes suspicious. Captchas (type the words that you see in a picture) are used to make sure that it’s a human instead of a computer. Computers have gotten increasingly good at decoding captchas, but at least it slows them down.
  • Sending a code to the user’s cellphone.
    Similar to captcha, you can send a one-time code to the user’s cellphone that will have to be entered online to continue. This is why so many websites now ask you for your number in the name of security.
  • Locking an account after a number of unsuccessful attempts.
    This is something that all banks do because the impact of somebody breaking in is can be devastating. The idea is that too many attempts will cause the account to be locked and the user will have to go through additional security to unlock it, such as calling by phone. An attacker can’t possibly try quadrillions of passwords under these circumstances.

There is another less common countermeasure. We know that with a simple desktop computer, a password such as “gotsec45″ can be broken in a few minutes. Imagine how quickly it will go with a room full of powerful computers.

  • Add a delay between unsuccessful attempts.
    If you force even a 5-second delay between attempts, it won’t matter how powerful the attacker’s computer is. It will take almost 32 thousand years to try all combinations to an 8-character password comprised of only lowercase letters.

Don’t rely on a single method. Use a combination of methods that makes sense for your business type and your users. Go ahead, give those methods a spin.

Do you use a countermeasure not mentioned here? Share it in the comments!

7 thoughts on “Brute-force countermeasures

  1. Don’t forget to throttle password reset requests too…those are too easy to forget about and super easy to exploit (especially the ones that ask “security” questions to restore the password).

  2. Bruno

    There’s a little honey pot trick I’m quite fond of. You simply add an input type text to your form and hide it with css. As far as I know, most robots ignore css. During the validation, if this field is populated, you know you are dealing with a robot and can react accordingly, for example by redirecting it to a fake site, or simply ignore its request and not submit the form.

    • Hah, clever! Then you can throttle the HTTP response and watch them moan. *evil laugh*

    • I used this trick too, and it’s proven pretty effective. But somehow, some bots get over this. But it’s definitely a great trick for low traffic websites.

    • Honestly, if you’re going to do this, go with a CSSRF token instead…you get a little extra validation and having a randomized token in there makes it even more difficult to abuse the form.

  3. I add a delay between attempts with the first failure incurring a 1 second delay but then the delay doubles after every failure. Even a butter fingered human will usually manage to log in without really noticing the delay but it really slows down automated attacks.

  4. Great points,
    I like the delay unsuccessful attempts point, probably will add it for all my projects.

    Thank you.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">