Orsdxy

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 ?

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

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.

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