Cdtjkyj

Locking accounts is a bad idea in the first place. It might seem like you're making your organization more secure by keeping out "bad people" who are "guessing" at passwords using brute force attacks, but what have you really solved? Even with this policy and a perfect userbase who never makes security mistakes, an attacker can perform a denial-of-service attack on your organization by repeatedly using the password "aaa" to lock out the accounts of critical users. Consider what happens if your attacker gets a copy of the list of usernames for your entire IT department: Suddenly, IT itself — the organization that would otherwise be able to unlock other users — is itself completely shut down.

Always consider what the threat model is before implementing a policy. A "bad guy" determined to hurt your organization will find alternative attack vectors. Your lockout policy won't even faze a nation-state actor (like Russia or China or the NSA); a determined hacker will just find other ways around it (like social engineering); and it will only hurt legitimate users of your service, no matter how low or high you set the lockout counter.

Moral of the story: Don't lock out accounts. Instead, do what Apple does with the iPhone: Each login try doubles the login delay, so that after a dozen failures or so, you have to wait one hour between each successive attempt. That's long enough to prevent "bad guys" from performing brute-force attacks, but still short enough that a legitimate user can spend that hour figuring out what their password was and typing it in properly after lunch — or contacting IT and apologetically asking for help. (Similarly, "flooding" policies can often be implemented at the IP-address level in your firewall, not just at the user-account level in your software, if you're concerned about a dedicated attacker trying to brute-force many different accounts.)

And if you don't lock out accounts, you don't need to have a counter — or display it.

[see also: this excellent answer on a similar question]

It depends on your lockout mechanism. If invalid logins get reset after some time AND a locked account does not get unlocked, showing a counter can help an attacker not to lock out an account. But a skilled attacker will have determined the lockout policy up front and will take this into account when guessing the password. So the impact is limited.

Also, relying on this to protect your login mechanism is missing the point. You should have a decent password policy and a lockout policy to match. If the password policy is strong, an attacker will have to guess a large number of times before getting it right. If you lock an account after 20 attempts, you have little chance of getting compromised.

You must ask yourself: what is the benefit of showing this information to a genuine user? Often, this problems with lockout occurs because the number of tries is set too low. 3 or 5 are common choices. NIST (Currently unavailable due to government shutdown so no direct reference yet) suggests less than 100 attempts.

NIST has a point: think of a password which no attacker will guess in 3 attempts, but which they will guess in 100 attempts. All attackers use different dictionaries and approaches. If a password is unsafe to withstand 100 guesses it can also be breached using fewer attempts - although that is less likely. Therefore a good password policy is a must.

I will add the NIST references when the site comes back up. Troy hunt has some good blog posts which summarize password and login mechanisms. He is a fan of the NIST guidelines as well.

Only two scenario is possible with it but rather showing account lockout time policy risk is more over lockout time.

E.g.

• once can configure the hydra or some other tool to brute force the login and wait after 3 attempts. if you don't have sufficient locking time it can cause an account compromise.




• if you have 30 mins or so locking time then its though we can configure the tool for brute force and wait after three attempts it will take years to crack the password.

to conclude this their no risk involve in displaying account lockout attempt.

I lean in general towards the less information you give to an attacker the better. As @security-beast mentioned a tool can be configured to wait the appropriate amount of time. Giving them the information for that configuration is not necessarily ideal.

However, you have to balance this with the needs of your users. Do you find that the system admins spend an inordinate amount of time unlocking accounts because your users keep locking them? If that's the case then your analysis may indicate that you get more benefit from displaying the number of retries to your users so they know when they need to wait before locking their accounts. In other cases the opposite will be true, but either way the answer should be the result of an objective analysis of the trade-offs for the particular system.

Hope this helps.

To give another perspective on this: it doesn't matter for a skilled attacker.

How are online accounts compromised today typically¹? There are two variations of one technique that are commonly used.

Databases with password hashes (or passwords in plaintext) get stolen and are cracked offline by attackers. After successfully cracking a hash the correct password is served to the login mechanism on the first try, so this control is ineffective.

This can either be the database of the service in question or the database of another service. Unfortunately people tend to reuse their passwords with several services so chances are high, that once a password is matched to an e-mail adress, it can be used on another site. An attacker might have two or three passwords to choose from, but probably not 20. Again, this control is ineffective.

So what level of security does this control establish? The level that is necessary to protect from inexperienced script kiddies, malicious ex-partners and nosy parents that want to take a look at your personal account and try five passwords at random. No more, but no less.

^{1 Then there are of course other techniques that are more "advanced" like keylogging, (spear)-phishing, MitM etc. which are as well not mitigated by this control.}

Based on the information provided we can't really answer this question. The frontend can display whatever developers want you to see and it has nothing to do with the security. How would you for a fact know that your account is locked on the backend? What does lock mean in this scope? There is an infinite number of possible configurations on the backend. If you design a system with this feature as an absolute must, then I'm sure there is a safe way of implementing it.

Security Risk is subjective it will depend on what you are trying to protect the objective of the security control and any other security control in place that mitigate or compensate the risk.

Based on this different companies / business will have different acceptance to same risk.

If in a generic way providing how many attempts your still have might not impose a risk (e.g.: PIN in your smart card to make phone calls)
In other situations it might be a risk (e.g.: trying to brute force mobile phone access) where you can stop before the last attempt and wait some time so the user resets the counter with a valid access...

You should check on the objective of the security control, what you are trying to protect and what security controls you have in place that will compensate or at least monitor abnormal situations.

Based on all this then you can decide if it is an acceptable risk or not for your specifics.