Xing \ Creative \ Coding

Web Application Software Development

Whenever possible, you should utilize existing frameworks that are well-maintained to handle your user logins. However, if you’ve inherited a project that handles its own logins, sometimes you simply have to make do and try to secure your application to the best of your ability.

Beyond using SSL, hashing your passwords, and making sure you salt your hashes…one of the other things you can do to improve the security of your website is to ensure you have some form of brute-force protection.

What is a Brute-Force Attack?

A brute-force attack is when someone is randomly or pseudo-randomly trying different passwords or keys to get into your system. Examples of brute-force attacks are:

  1. Session Hijacking: After a user logs in, they are often given a session key, typically placed in a cookie, that identifies them so that you know who they are on subsequent requests. If a person manages to “guess” a session key, they’ve gained access to your system and are able to perform actions as if they were the valid user.
  2. Password Cracking: An attacker, especially if they know a username or e-mail that is in your system, can attempt to “guess” the password. If you have no brute-force prevention measures, they are able to try thousands upon thousands of login attempts to try to get the right answer…only limited by your network capacity. If they manage to get a successful login, not only do they have access to that user’s account on your server, but since people often use the same passwords all over the place, they will probably be able to use that password to gain access to that user’s other accounts.

Securing Against Brute-Force Attacks

The goal of brute-force protection is not to completely prevent someone doing a brute-force attack, but rather to make it more time-consuming and costly than it is worth. Basically, you are just trying to slow them down.

In any case, first, to prevent Session Hijacking, you should ensure that your session keys are being generated by a cryptographically secure random generator. If you use something like PHP’s uniqid or a non-random Guid, since these are often non-random codes based on time, it’s very likely for a person to be able to guess the session keys that will get generated. Non-random keys mean that they are more guessable, and–thus–other brute-force prevention measures will not be as successful.

Second, for both Session Hijacking and Password Cracking prevention, you should log failed validations that occur by IP address. Here’s a quick design. I’ll use a database table, though you can also use a cache which may be more practical unless you want IPs to be able to be permanently blocked when they exceed some high threshold.

NOTE: IP addresses can be stored as integers (e.g. the ip2long method in php). This means you have to convert them on the way in and out, but it makes the indexing more optimized.

CREATE TABLE BruteForceLog (
    LastFailure  DATETIME NOT NULL

Once you have this table, the process is simple.  I’ll try to turn this into a work-flow in the near future, but for now, hopefully this is simple enough to understand:

  1. When a user-request comes in, load up its IP address (if any) from your BruteForceLog.
  2. If the FailedCount > YourPreferredCutOff and the LastFailure > (Now – YourPreferredTimeBlock), then block the request.
  3. Else, validate the session key / password against your sessions or user account.
  4. If the session key or password is invalid, create or increment the BruteForceLog and end the Request.
  5. Else, user is validated, continue.
You may have noticed on some sites that implement this, once you’ve exceeded the limit, it still tells you that you have an invalid password rather than telling you that your IP is blocked. So, you technically don’t know when you’ve exceeded the FailedCount limit. This is an additional security measure so that brute-force attackers don’t know how many of their brute-force attempts are actually being checked…giving some small additional security. However, this ambiguity itself is less important than delaying their attempts.

August 22nd, 2017

Posted In: Security

Tags: , , ,

Leave a Comment