Brute Force Attack Prevention Mistake 3: Using A Session

One of the first steps in developing custom brute force prevention is keeping track of failed login attempts. You then decide how many failed attempts you will allow before attempting to prevent any more unauthorized attempts. You realize that you must come up with a way to store the failed attempts so you decide to use a session variable (a common choice).

PHP BASIC SESSION EXAMPLE

session_start();
if ($_SESSION['logged_in'] == ‘failed’) {
$_SESSION['failed_attempts'] = $_SESSION['failed_attempts'] + 1;
if ($_SESSION['failed_attempts'] == 5) {
$query = “INSERT INTO `blocked_users` ( `block_id` , `user_id` , `date` ) VALUES (”, ‘$user_id’, ‘$date’)”;
$insert = mysql_query($query);
echo ‘This Account Has Been Locked Out’;
}
}

From the simple code example above, you can see that it stores failed attempts in a $_SESSION variable. Once it reaches 5 failed login attempts, it makes a database entry to block or lock the account. Unfortunately, this is a huge brute force prevention mistake. Sessions are primarily stored in one of two locations. They are stored in a cookie that resides on the client side or they reside in the URL. With this being said, your largest brute force threat is a brute force script or program. These brute force tools do not create and store cookies. Each authentication attempt is made with a unique request. This means that the brute force tool does not hold open a session and therefore every new request is assigned a new session. This means that the script can send countless authentication attempts and it will never get blocked. By using a session your are only protecting yourself against the malicious user who sits and manually makes authentication attempts. This user can still make 4 attempts, close their browser or clear their cookies, and then reopen the page to try again and they will never get blocked. As you can see, using a session to store failed login attempts is a big mistake.

Solution: Use a database to store your failed login attempts. When an authentication request is made, that request can be uniquely identified by several characteristics. One common identifier is the IP address of the request. You can use these identifiers or a combination of identifiers to track failed authentication attempts in a database. Using a database will allow you to track failed attempts for any user, script, or tool.

No Comment

No comments yet

Leave a reply