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?

  • What do you mean it's all meaningless with the correct password? Do you mean if their account is locked out, and they log in with the correct password while its locked out?
    – Steve
    Commented Jun 8, 2011 at 15:32
  • 10
    @Sonny I think you are entirely missing the point. When it locks the user out for a period of time, it will not accept any password during that time, including a correct password. Commented Jun 8, 2011 at 20:53
  • @AttackingHobo, I understand that this is the idea, but in practice this is not what is happening, and a correct password will log in. I assume Hotmail and Gmail have done this to prevent simply DoS attacks, but it would seem to defeat the purpose. Commented Jun 8, 2011 at 23:12
  • 3
    Can you provide any evidence for your assertion that this is how gmail and hotmail work? All the other reports are that you're wrong, and it would indeed be a huge error to implement it that way
    – nealmcb
    Commented Jun 9, 2011 at 19:23
  • 1
    Gmail doesn't work like this. You have to enter a captcha to try additional passwords. A correct password alone is not enough. This prevents online password guessing attacks. Commented Aug 19, 2014 at 3:45

6 Answers 6


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).

  • Plus, the actual account owner sees that someone was trying passwords on his account. If they'd just add a "list of last 1000 dates and IP-addresses that accessed your account", it would prevent a lot of "lurkers"...
    – Konerak
    Commented Jun 8, 2011 at 19:06
  • 1
    Hi Thomas, great answer. I just noticed with Hotmail for example if you put in X amount of wrong passwords you get a message saying login attempts are disabled, but you can login immediately with the correct password. That seemed to be ineffective to me. Commented Jun 8, 2011 at 23:15
  • 1
    @Sonny, ineffective, yes, but also completely incorrect.
    – AviD
    Commented Jun 9, 2011 at 22:33
  • @AviD how is that completely incorrect? I try several incorrect passwords and get a message saying login attempts are restricted and can then logon with my correct password. Commented Feb 1, 2012 at 0:51
  • 1
    @caseyr547, if they have the correct password from an earlier breach (and the user has the same password and hasn't changed it), then there is absolutely nothing we can do to prevent a hijack of that account. This technique of delaying the login is only meant to prevent brute force attacks against an online system. And yes, they don't "fix" the problem, they only string it out until it's impossible for the hacker to possibly try every password before the end of the solar system. Commented Aug 19, 2014 at 9:14

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.


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.

  • 3
    Right on! In my mind security is part of a delicate balancing act between usability, cost, and security. Make the system too expensive and no one will buy it (or you won't be able to cover your costs). Make the system too hard to use, and less people will want to use your system. Make it too insecure and you will lose the value you were trying to protect.
    – this.josh
    Commented Jun 8, 2011 at 22:27
  • 1
    You must also take in account the ability for an attacker to lock out legitimate users. Too often I see systems like that acting as enabler to cheap denial of service. Commented Jun 22, 2011 at 13:07

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.


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...

  • Any justification for the down vote?
    – corrector
    Commented Sep 22, 2011 at 19:11
  • 1
    Pretty much the same as the others I've addressed. Please join us in chat (chat.stackexchange.com/rooms/151/the-dmz) or post in meta (meta.security.stackexchange.com) if you'd like to discuss this further.
    – Iszi
    Commented Sep 22, 2011 at 20:24
  • +1 because neither the downvote itself nor the link in answer make obvious sense
    – goblinbox
    Commented Feb 8, 2012 at 18:41
  • no this is bad users are not sec experts
    – user42209
    Commented Aug 19, 2014 at 3:07

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .