Is displaying remaining password retry count a security risk?

Question

Some websites display a remaining password retry count when I input wrong passwords more than twice. For example, displaying that there are 3 retries remaining until locking out my account. Is this dangerous from security perspective ?

Answer 1

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]

Answer 2

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.

Answer 3

In principle, no, it should not be a security risk. If it were, then you would be relying on security through obscurity (hidden information).

Hiding a count would, at best, be a minor inconvenience to an adversary.

In contrast, hiding a count can be a significant inconvenience to legitimate users. It's not uncommon that I sometimes enter the wrong password and then re-enter it a few more times assuming that I made a typo. If I know that I will be locked out with another incorrect attempt, I'll go look up my password and copy/paste or type it carefully. If, however, I unwittingly lock myself out of my account, now I need to go through a lot of extra trouble to get it unlocked.

Answer 4

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

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

At some point I was at a company where they just had a few guys test their security. One of these things those guys found is that the there was no account lockout when there where too many incorrect passwords. However much to the CISO's delight they could not prove that they could actually get in by brute forcing the password. The reason for this was that the account lockout was silent and lasted for about 15 minutes.

Ask yourself what you gain by displaying such a message and what you lose in security by doing so. It is perfectly valid to not give any notification of locking an accoutn due to too many incorrect login attempts. If you give such a message you will just help an attacker in figuring out when he is wasting his time brute forcing. If you don't they are less likely to figure it out but it might lead to more calls/mails to your helpdesk which might be costly. An FAQ or help page might reduce this.

Also implementing the countdown will, probably, mean more code and more code means more bugs. This is not something you want in a security mechanism. Add to that that you implement it wrong it might allow attackers to enumerate usernames which is doubly problematic if they are email addresses. Hell, if you implement it using an unsigned cookie it might actually give the attacker the ability to prevent a lockout happening at all.

In general your security will be improved if your error messages give as little information as possible.