Brute Force Attacks

April 15th, 2008 | by admin | |

One of the most common and simple attacks to applications are often the
Brute Force Attack, where username and password combinations are tried
until access is gained. How do we prevent against such attacks? The
answers are simple and important to implement in your applications from
the very beginning.

Brute Force Attacks (password guessing)

Introduction to Brute Force

One of the simplest hacking attacks on application security is the brute force attack, where all possible password/key combinations are tried until success is reached. This type of attack is more commonly associated with ATM cards, where the card is inserted and all PIN combinations tried until a success result is found.

With applications, think of your username as your ATM card and your password as your PIN. By using a combination of username and password, brute force attacking quickly becomes very inefficient, to the point of near impossible when usernames are not known, due to the combination of possibilities. However, once a hacker knows your username, they can plug that in as a constant and cracking the password becomes somewhat easier.

Simple Avoidance 1 - Password Policy

While we try to keep our usernames to ourselves, sometimes they are easy to guess, or appear on the screen or on printed out material. So we need to assume that a hacker would be able to get a hold of a username to our system and just ‘brute force attack’ away at the password until they gain entry. Which is why password policies are extremely important, forcing your users to create strong passwords, making passwords both hard to guess and hard to crack via brute force.

Your application should have security designed to distinguish between upper and lower case characters of usernames and passwords (you”d be surprised at the number of applications that do not). Your password policy should enforce some, or all of the following simple rules:

  • Passwords must be 8 characters or longer
  • Passwords must include both letters and numbers
  • Passwords must include both upper and lowercase letters
  • Passwords must not include the username in any part of itself

Follow these rules and you can be assured that your users are using strong passwords that are both hard to guess and crack.

Simple Avoidance 2 - Give Nothing Away

One other thing you need to be aware of is the messages you return in your applications upon login attempts. If the username entered does not exist in your system, don’t return a message indicating as much. Oh so many systems tell you “Sorry, the username you have entered does not exist”, allowing a hacker to try a brute force attack on your application until they get a different message, which would indicate that they have found a valid username.

As a general rule, always use a single default message for unsuccessful username/password login attempts. Something along the lines of: “Login attempt unsuccessful”.

Advanced Avoidance 1 - x Many Unsuccessful Logins

Good security in your applications will detect brute force attacks by logging the number of times a certain username has unsuccessful login attempts. If username ”marks” has tried to login 5 times unsuccessfully, there’’s a good chance someone is trying different passwords in an attempt to gain entry. It is always good practice to make accounts inactive when 5 unsuccessful logins have been tried, and keep the user account inactive until either:

  1. the user calls/emails tech support asking for access and their identity can be confirmed
  2. a certain time period is reached (ie. 1 hour until they can try to login again)

The beauty of option 2 is that the system can remain automated, requiring no technical support to re-activate accounts. You can simply inform the user on the login screen that they need to wail an hour until they can attempt to login again.

Advanced Avoidance 2 - Security Tokens

Security tokens are a randomly generated key (token) that adds another layer of security for a given username. How the process works (or should work) is your users have a standard login screen, but also a separate application designed to generate a security token for their account that is valid for X amount of time. Some businesses do this via an instant messaging system with mobile phones - user sends an SMS, and the system sends them a security token for their online account, which is valid for X minutes/hours.

The point is, the user account is inactive until a security token is generated, and security tokens are only valid for so long, so even if a hacker knew your username and password, they would have to hack your account when you have requested a token and only in the given time frame that the token is valid for. Pretty neat huh. The only problem of course is that this makes more work for your users, who now have to request a security token whenever they want to login, and as we know, users don”t like small inconveniences like this. However, some applications contain very sensitive data and measures like this are necessary. You know your system, you be the judge. But for most systems, security tokens may be a bit overboard.

Post a Comment