Relative advantages of blacklisting IPs vs locking accounts

We are designing a security system to prevent brute force attacks to get into an account.

One option proposed is blacklisting by IP. If an IP address attempts to login too many times, any further attempts by that IP address are blocked for a given time.

Another option is to do a more traditional account lockout, where too many attempts on a given account locks out the account until the password is reset.

The issue with the first approach is customer service - if a legitimate user calls to get back in, they just have to wait it out - their IP is blacklisted for the time period.

The issue with the second is that it opens a DoS attack, given knowledge of a legitimate user name, anyone can put in bogus passwords to lock them out.

What experi开发者_Python百科ences have you had in different approaches to preventing brute force attacks against user accounts?

Lists of tens of thousands of proxy servers can be bought or easily obtained by scanning(YAPH). There is software like THC-Hydra which can use lists of proxy servers for brute force. That is not to say that IP address black lists are bad, they raise the bar for the attacker.

Account based locking can be used against you. A hacker will need a list of user accounts, often the hacker doesn't care what account is broken. The first phase of attack against this system would be to try as many user names as possible, once you have a list of names then you go back and try weak passwords for each one.

The solution I like is to force the user to solve a capthca after maybe 5 failed logins. You can go with a blended approach of ip addresses and account names. If someone tries 5 failed logins from an ip address, you force that ip address to solve a capthca. If 5 failed login attempts for ANY login name, then that login name will require a captcha. But there is a potential problem, if someone is trying to brute force account names then you cannot act differently if the account doesn't exist. Thus you will have to ask for the user to solve a capthca on non-existent accounts which are also "locked" due to brute force.

Leaking account names to an attacker greatly aids in brute force. I recommend looking over your application to make sure you aren't leaking login names.

I second the idea of adding delay to the next login attempt, but add the addition of checking against incoming IP as well as attempted user account. So regardless of username used, if it came from the same IP more than some number of times start a exponentially growing login delay. This also ensures that attackers gain no information as to whether they are trying legit user names or non-existent user names.

Blacklisting IPs is essentially useless (already discussed here - see TOR/Proxy).

Locking the user account is bad CR (causes more headache for legit users than solving problems)

Adding captcha's is just silly (http://www.theinquirer.net/inquirer/news/1040158/captchas-easily-hackable). Haven't you all heard about how easily captcha's are hacked these days? Plus they are even more of a pain for legit users.

Delaying the next login makes brute force attempts impractical while still allowing legit users full access to their account when needed.

Blacklisting IP's is impractical these days. You'll alienate users of Tor or other similar proxies.

I'd suggest locking the account.

If DoS attacks are a concern then make it a self-expiring lock, or limit the login rate attempt.

Sample Rules

if failed_attempts > 5
  if last_attempt < 30 seconds ago
    error("You must wait 30 seconds before your next login attempt")
  else
    authenticate(user,pass)

You should couple this with some good-sense password strength requirements.

I think that blacklisting by IP addresses and user names is the best option. It defends against two types of attacks: specific (for one user) and generic password guessing.

The issue with the user blocking is that someone can automate this kind of attack to cause a DoS, denying all users access to the resource. So, that without an IP blocking is not useful.

Btw, take a look at http://www.ossec.net . It automates "active responses" based on any type of log, with a low timeout period (10 minutes) to avoid those issues.