Are Three attempts to block login a good idea?

Question

In the company that I work there is a security rule:

If you enter your password 3 times wrong, your login will be blocked! 

Then I have to go to mainframe program and re-register my new password. First I make a login in this program with my blocked password, so it still works for this.

If I type the password wrong 8 times in this program, only my boss can unlock my accuont.

The major problem is the firewall. If this is configured with a wrong password, is easy for firewall try more than 3 times. This can be a headache to fix.

Is this a common security rule or just a stupid one?

Answer 1

While Rory's answer is pretty much spot-on, I'd also add that account lockout after X attempts, in certain contexts, can be an easy way to cause a denial of service (DoS) against a legitimate user.

Imagine if a webmail provider (like gmail) worked this way. If I want to cause you a temporary DoS, all I'd need to do is try to login as you with three (or 5, or however many it takes... the actual number doesn't really matter too much) times with the wrong password. The webmail provider would then lock your account and when you, even though you know your password, went to log in, it would not authenticate you.

This is why such lockout policies aren't too common with publicly-accessible sites these days. A better approach is to put an increasingly larger delay between password prompts, which will deter script-kiddies but still allow you a chance to enter your password. Even better is using another factor, like the source IP of the login attempts in deciding to slow-down the login prompt (or display a captcha in the case of Google accounts).

Just something to think about when debating this type of policy. Cheers.

Answer 2

Essentially if you look at account lockout it's designed to mitigate the risk of an online password guessing attack.

If there is a reasonable password rule in place (eg, 8 character + with complexity and a check for common passwords), it's fairly unlikely that an online password guessing attack would be successful in a low number of attempts.

Also it's worth considering the user unfriendliness of lockouts occurring + business cost of lost work. So as with anything in security it's a trade-off.

FWIW I'd suggest that for many systems 5-10 is a more reasonable number. whilst it's fairly easy to mistype a password 2 or 3 times, by the time you get to 10 it's reasonable to assume that the user has forgotten it.

One other factor to consider though is the regulatory risk. Auditors tend to have fixed ideas on this one, and a lot of their scripts may say that anything over 3 is a problem...

Microsoft have a white paper on this here which goes into some detail on this topic.

Answer 3

Is this a common security rule or just a stupid one?

It is an extremely common policy, and arguably, due to the denial of service attack it implies, also a stupid one.

It's pretty standard in enterprises. You could argue it makes more sense here where there is a company helpdesk to cope with the fallout, and you would hope little motivation for another employee to be taking advantage of the DoS. In this context it is also required by some security standards, eg PCI DSS. In a consumer-facing context, where you have a greater range of potential attackers and higher costs in supporting locked-out users, it would be a worse trade-off.

The attack it is attempting to block is that of brute-force guessing a particular targeted user's account. If you want to get rid of account lockout you'd have to find some alternative mitigation for that attack. That might include:

• harsher password complexity requirements: increasing the entropy in a password could greatly increase the number of guesses expected to get a breach;

• two-factor authentication; potentially, using additional weak factors like IP addresses, device profiles and behaviour patterns to make a risk judgement and potentially prompt for a second factor or an additional authenticator;

• rate-limiting based on IP/reputation, to slow down access to the login interface progressively when there are many recent failed logins.

Because the account lockout mechanism does not attempt to guard against the scenario of brute-force guessing across many accounts (eg, the ‘inverted password guessing’ attack of picking a common password and trying it across many accounts), you may well want to consider some of these approaches in any case. (The other traditional mitigation against this kind of attack is to keep the usernames semi-secret, protecting against username enumeration, but this is a bit weak and can be hard to cover completely for some kinds of system.)

I'm not sure what might be appropriate in your particular situation but since you mention a ‘mainframe’ my suspicion would be a legacy system with little scope for change. It's also not clear what kind of ‘firewall’ would be concerned with user passwords—are you talking about web proxy authentication?