Is this an effective way to prevent brute force attacks?

Question

I need your opinions on whether or not this is an effective way of preventing brute force attacks for user logins:

1. If the user incorrectly types the password to the account 5 times, they are locked out for 5 minutes.
2. Upon getting locked out, a record is added to my database that holds the user_id and the time at which the user can attempt to log back into that account.
3. After the 5 minutes is up, when they next try to login, it will check the database to see if the lockout time is up. If it is, they have another 5 attempts, if not, show an error.

Is this anti-brute-force proof?

Thanks.

Answer 1

There is a very old, and so far the best, method of preventing brute force. It originated many years ago in unix and, so far, is still valid. It is also very simple to implement: add sleep(3) to every login attempt. Normal user won't have any issue with having to wait extra 3 seconds on the login action, and this coupled with proper firewall that limits amount of connections from single host is the most efficient brute force killer.

Answer 2

I think a doubling delay time combined with a multiword password phrase (think "stack overflow answers", probably add something simple yet easy to remember so we're good against dictionary attacks as well) would be almost completely brute-force-proof as well as unobtrusive towards users. Here is what I mean, let's assume the initial interval of 1 second:

• 1st fail: 1 sec delay
• 2nd fail: 2 sec delay
• 3rd fail: 4 sec delay
• 4th fail: 8 sec delay
• etc...

At this point probably every legit user would figure out he has forgotten the password and would look for a way to reset it.

Answer 3

You are on the correct track. You should increment a counter field for the user in the database for each consecutive invalid password attempt. If you are trying to hold that value in a session or cookie, a malicious user could keep destroying that and retrying after 4 attempts.

I employ a similar strategy -- after 5 wrong attempts, we require captcha. After 10 wrong attempts, we block the account until reset. We have a reset password and unlock strategy in place, as well.

Someone had mentioned a sleep(3) strategy. While, it's a good idea to not return responses for user authentication too quickly, it's probably not tamper-proof. An attacker could spawn a series of concurrent authentication requests, instead of a quick series of consecutive requests. At least, with your strategy, you know they are only getting 2400 guesses per day, per user. Consider cutting off the user for longer periods than 5 minutes, especially once they pass 10 or 15 guesses.

For the paranoid, log additional data with each of the bad attempts, such as IP address, user agent string, and other http headers in the request. You may be able to identify patterns in the event of a real attack.

Consider including logging and alerting appropriate personnel for when a user is locked out.

Answer 4

Here are some options:

Locking Account

You lock the accounts for some time, after some number of incorrect login attempts.

Problems:

• Ineffective against slow attacks that try only a few logins on relative large intervals of time.
• The attacker can lock a lot of accounts, consider this a DoS.
• The attacker can get some info of your site, dependeing on the error responses.

Locking IP

You lock the IP with varius failed logins.

Problems:

• This can lock large groups of users
• Ineffective against automated tools that use proxys.

Do pauses

You do pauses when checking the password, this will slow the attack.

Problems:

• The attack can be multi-threaded, so you are more or less in the same situation.

Captcha

There are good algorithms that can correctly identify that weird shapes/letters/numers.

The captcha is not 100% effective, but could slow down the attack.

Login for certain IPs

Give the users the option to allow login only from certain IP's.

• This is not practical for every user.

Add no predictable behavior

For example, use different error messages each time when a login fails, this could mislead automated tools.

Answer 5

Yes it will restrict bruteforce . but some recovery procedure should be there for the legitimate users.