Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question
    
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 Jun 8 '11 at 15:32
8  
@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. –  AttackingHobo Jun 8 '11 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. –  Sonny Ordell Jun 8 '11 at 23:12
    
I don't know what to say, and I don't really want to get my account locked right now, but before after I had changed my password to a new one, I forgot what it was for a bit, and got locked out. When I remembered it, it would not accept it yet. –  AttackingHobo Jun 8 '11 at 23:17
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 Jun 9 '11 at 19:23

7 Answers 7

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

share|improve this answer
    
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 Jun 8 '11 at 19:06
    
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. –  Sonny Ordell Jun 8 '11 at 23:15
1  
@Sonny, ineffective, yes, but also completely incorrect. –  AviD Jun 9 '11 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. –  Sonny Ordell Feb 1 '12 at 0:51
    
@Thomas Unforunately you risk denial of service attacks by locking the account unless it is session specific or some other means of only locking an account to a specific requester. There were a number of apps floating around back in the day that allowed attackers to send bogus login attempts to keep accounts locked permanently while they were running. However if you make it session specific then this too can be easily defeated by running the POST requests through a list of proxy servers. –  Taipo Feb 8 '12 at 20:38

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.

share|improve this answer

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.

share|improve this answer
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 Jun 8 '11 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. –  Bruno Rohée Jun 22 '11 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.

share|improve this answer

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

share|improve this answer
    
Any justification for the down vote? –  corrector Sep 22 '11 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 Sep 22 '11 at 20:24
    
+1 because neither the downvote itself nor the link in answer make obvious sense –  goblinbox Feb 8 '12 at 18:41
    
no this is bad users are not sec experts –  caseyr547 2 days ago

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.

share|improve this answer

Do exactly what Google and Chase are doing; multilayered authentication.

  1. Don't accept logins from random computers verify the identity of the user at their first log in from a device and forget devices after so long.

  2. After a number of bad attempts lock the account with a catpcha. Captchas are meaningless to security but they force the user to think a little harder when they input their password.

  3. After the captcha passes but the password fails once lock the account for further password input for a set time with override through direct human communication with someone trained to deal with social engineering/hacking.

  4. After time passes and the user enters the correct password: direct the user to verify with physical information like a text or call to a cell phone or if you feel like being less secure an email to the trusted address.

  5. Flag accounts which have problems and limit their access because every system has its flaws.

Anything besides some physical verification is meaningless so hotmail is doing it wrong when you wrote this question.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.