Is denying login after incorrect attempts ineffective?

Question

Generally denying login attempts after X amounts of incorrect attempts for Y amount of tries is a very basic way to prevent bruteforce attempts or malicious login attempts.

Yet, surely doing this is meaningless if you allow successful login with the correct password? In which case getting an error or a warning message about a timeout period when trying an incorrect message is meaningless if the correct password will work regardless.

On Hotmail for example when I attempt to login with the wrong password I eventually get a message saying further login attempts are restricted. Trying with the correct password lets me in straight away. So I wonder if there is any point to having such a warning in the first place? Is it effective in the actual password grants access?

Answer 1

Preventing login without the right password is the core functionality of the login process. Just keeping on doing that is by no means an "additional" security feature.

Denying login attempts after X incorrect attempts means rejecting all attempts in that situation, regardless of the value of the password which is then presented. If you still accept the right password, then you are not denying anything, you are just managing a login process.

With online systems, disabling the account is a bit rash; it means that anybody can effectively block your account by entering junk passwords. A smoother procedure is to add delays: after X incorrect passwords, have the server block the account for, say, one minute, and reblock it for one minute after every attempt until the right password is entered. The initial X attempts should be enough to cope with users with shaky fingers, and the one-per-minute rate severely impedes a bruteforcing attacker (coupled with some safety measures such as banning IPs from which too many login request come in too little time).

Answer 2

The idea is to not even accept the correct password during lock down.

But before implementing a lock down system, it makes sense to look at the attack cases:

a specific user is targeted

If the attacker is targeting a specific user, denying or delaying logins after a couple of wrong tries is helpful. A common mistake with the delaying approach is not to prevent parallel logins attempts.

Another common approach is to use CAPTCHAs to slow down the attacker. One needs to keep in mind that many standard CAPTCHAs are already broken. When the NY-Times voting was manipulated, the attackers crafted a special interface which display many CAPTCHAs on one page.

The attacker may try only two login attempts every day over a long period of time (we actually see this in Stendhal from time to time). Displaying the number of failed login attempts after a successful login may help here. It's important to not say "0 failed login attempts" every time because this will just teach the people to ignore that message. Only show the warning if there was at least one failed login attempt.

A list of ip-addresses and timestamps of the last login attempts (successful or not) may help, at least for users who care about security and have a certain level of knowledge.

any user is target

In cases in which a really large number of logins are attempted, the attackers often pick a fixed password and brute force the account names. This means that a threshold of three login attempts per account will not be triggered.

So failed login attempts need to be tracked on a cross account basis, for example based on the ip-addresses.

locking out a large number of users

Implementing the counter measurements mentioned above creates a new vulnerability: An attacker can lockout a large number of accounts. In some cases this may cause far greater damage to a site than a small number of hacked accounts.

IP-based counting can help to mitigate this attack vector. Or it can give a lever to it in situations in which lots of people are behind the same proxy server (at an university, or public wlan, etc.)

locking out a specific account

In addition to the last section, an attacker may try to lockout a specific account. For example someone who is bidding against them on an auction.

It may be possible to use a second channel to allow the account owner to re-enable his account. For example by sending a mobile text message or email with a code.

Answer 3

I like Thomas Pornin's answer. My only addition would be - when you design a password lockout feature, you need to figure out how to support your user base and balance that with the risk of breakins.

In a high security system with a limited number of security-savvy users, dedicated admins and a big budget for user support, enabling a locked out password may be manual and may require a re-authentication through a secondary channel that is expensive and time consuming.

In a low-security system with a huge (and maybe even computer illiterate) user base - like Google or Hotmail - the risk of a break in is likely to be overruled by the expense of supporting account unlock through anything except a highly automated, very simple, process.

I've seen systems that were so simple, that all they did was force-close the browser when 3 bad passwords were reached. Slightly better is the system Thomas proposed with a timeout on disabled accounts. In my experience, systems do this to provide a moderate barrier to bruteforce attacks while balancing the needs of tons of users who are trying to access their accounts.

It's true that it's not the greatest approach - but systems need to find some way to slow down attacks while not dealing with users face to face, since every support call costs the provider money - so with free services like Gmail, you get what you pay for.

Answer 4

I would suggest that you not only lock out a user profile that gets too many bad passwords ... but also block the IP of a machine that gets too many bad passwords (possibly with multiple accounts).

I use DenyHosts on my linux machines to block IP's that get try to guess passwords.

Answer 5

I think you should let the user determine how "random" his password is.

For some "passwords", it just doesn't make sense to put a limit: some users generate their "passwords" automatically (making them impossible to remember) and keep these in a file, so these passwords are more like crypto keys than normal passwords.

I believe that letting the user choose how many tries before the account gets a 10 s, 30 s, 1 mn login time penalty, and how many before the account is locked for 1 h, 12 h, 1 d, with or w/o CAPTCHA recourse would force user to think more about the strength of their password.

Then you are not just giving some freedom to people, you are forcing this freedom on users: every user would have to choose a locking-out policy.

Also a user should be allowed to a link his account to some RBL to prevent login from open SOCKS relays or from Tor exits (defaulting to no RBL subscribed).

For Web applications, a user should have the right to choose between pure HTTP-based auth (HTTP-auth, cookies,...) or HTTP-based + IP addr-based auth (binding a logged-in user to one IP) (defaulting to just HTTP-based auth, no IP addr binding).

I think you should aggressively give freedom and responsibility to users. This way they cannot cry in forums when they have been hacked, saying that the password system setup was weak, insecure, non professional...

Answer 6

It depends a lot on what type of account the user is attempting to access. Web based email accounts are the usual example where the email is the username, however in other cases it is better to not use the email as the username therefore the attacker would not have the user credentials in the first place in order to dictionary crack the password.

Any form of account locking without captchas or some other form of mass POST prevention can lead to denial of service where an attack tool is used to send multiple requests for the expressed purposes of causing account locks.

Using non-email or names is the standard with website account logins such as Godaddy and others, and also bank account logins for example, although these tend to be number strings which opens them up to user specific denial of service attacks via mass brute force attacks on number string blocks.

ex: user: 1000000++ pass: a-zA-Z0-9

An attack sending 4 attempts on a sequential username where the bank has set the user to be a range of numbers like 48829387 could easily allow an attacker to deny logins to a large range of bank users by going over the limit of allowed incorrect password requests to random numbers between the ranges of say 4000000 and 4999999.

In most web login situations though, having users choose a username separate to their name or email address is asking a bit much, and is probably why banks often use number strings as usernames.

So if difficult usernames are not available as an option, then preventing dictionary hammering is the next port of call by either the use of captchas or even demanding javascript before establishing sessions as often these dictionary type attack tools lack the ability to deal with returning cookies let alone sessons established after javascript is detected.