Mixing
Is displaying remaining password retry count a security risk?
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 ?
authentication password-policy account-security
edited Jan 16 at 9:16
Snappie
297126
asked Jan 16 at 8:11
Ahmet ArslanAhmet Arslan
481128
|
show 9 more comments
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 ?
authentication password-policy account-security
edited Jan 16 at 9:16
Snappie
297126
asked Jan 16 at 8:11
Ahmet ArslanAhmet Arslan
481128
49
One consideration is that this can easily reveal whether a username exists on the site. This may be undesirable if user names are emails and the site is something personal like foot-fetish.com You can avoid this by returning a fake number for non-existent accounts
– paj28
Jan 16 at 16:25
11
Would it be so implausibly difficult for a hacker to count the number of failed attempts before receiving the locked account message? By this logic you should be asking whether displaying the "Account locked" message is a security risk.
– MonkeyZeus
Jan 16 at 16:51
3
@MonkeyZeus But with a number displayed the hacker knows when to stop before the account gets blocked and the failed attempt gets noticed. They then can wait some time until the owner logged in and resets the counter.
– BlackJack
Jan 16 at 17:45
5
Why has nobody considered that the retry count could be based on ip or device recognition?
– Nightwolf
Jan 17 at 8:34
10
no no no... do NOT lock out IPs for WEBSITE logins. SSH? Sure. But a lot of companies/schools/apartment complexes/hotels/etc NAT their entire internal space out through a single IP, and you could block a ton of unaffiliated users by banning by IP.
– Angelo Schilling
Jan 18 at 23:11
|
show 9 more comments
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 ?
authentication password-policy account-security
edited Jan 16 at 9:16
Snappie
297126
asked Jan 16 at 8:11
Ahmet ArslanAhmet Arslan
481128
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 ?
authentication password-policy account-security
authentication password-policy account-security
edited Jan 16 at 9:16
Snappie
297126
asked Jan 16 at 8:11
Ahmet ArslanAhmet Arslan
481128
edited Jan 16 at 9:16
Snappie
297126
asked Jan 16 at 8:11
Ahmet ArslanAhmet Arslan
481128
edited Jan 16 at 9:16
Snappie
297126
edited Jan 16 at 9:16
Snappie
297126
edited Jan 16 at 9:16
Snappie
297126
297126
asked Jan 16 at 8:11
Ahmet ArslanAhmet Arslan
481128
asked Jan 16 at 8:11
Ahmet ArslanAhmet Arslan
481128
asked Jan 16 at 8:11
Ahmet ArslanAhmet Arslan
481128
481128
49
One consideration is that this can easily reveal whether a username exists on the site. This may be undesirable if user names are emails and the site is something personal like foot-fetish.com You can avoid this by returning a fake number for non-existent accounts
– paj28
Jan 16 at 16:25
11
Would it be so implausibly difficult for a hacker to count the number of failed attempts before receiving the locked account message? By this logic you should be asking whether displaying the "Account locked" message is a security risk.
– MonkeyZeus
Jan 16 at 16:51
3
@MonkeyZeus But with a number displayed the hacker knows when to stop before the account gets blocked and the failed attempt gets noticed. They then can wait some time until the owner logged in and resets the counter.
– BlackJack
Jan 16 at 17:45
5
Why has nobody considered that the retry count could be based on ip or device recognition?
– Nightwolf
Jan 17 at 8:34
10
no no no... do NOT lock out IPs for WEBSITE logins. SSH? Sure. But a lot of companies/schools/apartment complexes/hotels/etc NAT their entire internal space out through a single IP, and you could block a ton of unaffiliated users by banning by IP.
– Angelo Schilling
Jan 18 at 23:11
|
show 9 more comments
49
One consideration is that this can easily reveal whether a username exists on the site. This may be undesirable if user names are emails and the site is something personal like foot-fetish.com You can avoid this by returning a fake number for non-existent accounts
– paj28
Jan 16 at 16:25
11
Would it be so implausibly difficult for a hacker to count the number of failed attempts before receiving the locked account message? By this logic you should be asking whether displaying the "Account locked" message is a security risk.
– MonkeyZeus
Jan 16 at 16:51
3
@MonkeyZeus But with a number displayed the hacker knows when to stop before the account gets blocked and the failed attempt gets noticed. They then can wait some time until the owner logged in and resets the counter.
– BlackJack
Jan 16 at 17:45
5
Why has nobody considered that the retry count could be based on ip or device recognition?
– Nightwolf
Jan 17 at 8:34
10
no no no... do NOT lock out IPs for WEBSITE logins. SSH? Sure. But a lot of companies/schools/apartment complexes/hotels/etc NAT their entire internal space out through a single IP, and you could block a ton of unaffiliated users by banning by IP.
– Angelo Schilling
Jan 18 at 23:11
49
49
One consideration is that this can easily reveal whether a username exists on the site. This may be undesirable if user names are emails and the site is something personal like foot-fetish.com You can avoid this by returning a fake number for non-existent accounts
– paj28
Jan 16 at 16:25
One consideration is that this can easily reveal whether a username exists on the site. This may be undesirable if user names are emails and the site is something personal like foot-fetish.com You can avoid this by returning a fake number for non-existent accounts
– paj28
Jan 16 at 16:25
11
11
Would it be so implausibly difficult for a hacker to count the number of failed attempts before receiving the locked account message? By this logic you should be asking whether displaying the "Account locked" message is a security risk.
– MonkeyZeus
Jan 16 at 16:51
Would it be so implausibly difficult for a hacker to count the number of failed attempts before receiving the locked account message? By this logic you should be asking whether displaying the "Account locked" message is a security risk.
– MonkeyZeus
Jan 16 at 16:51
3
3
@MonkeyZeus But with a number displayed the hacker knows when to stop before the account gets blocked and the failed attempt gets noticed. They then can wait some time until the owner logged in and resets the counter.
– BlackJack
Jan 16 at 17:45
@MonkeyZeus But with a number displayed the hacker knows when to stop before the account gets blocked and the failed attempt gets noticed. They then can wait some time until the owner logged in and resets the counter.
– BlackJack
Jan 16 at 17:45
5
5
Why has nobody considered that the retry count could be based on ip or device recognition?
– Nightwolf
Jan 17 at 8:34
Why has nobody considered that the retry count could be based on ip or device recognition?
– Nightwolf
Jan 17 at 8:34
10
10
no no no... do NOT lock out IPs for WEBSITE logins. SSH? Sure. But a lot of companies/schools/apartment complexes/hotels/etc NAT their entire internal space out through a single IP, and you could block a ton of unaffiliated users by banning by IP.
– Angelo Schilling
Jan 18 at 23:11
no no no... do NOT lock out IPs for WEBSITE logins. SSH? Sure. But a lot of companies/schools/apartment complexes/hotels/etc NAT their entire internal space out through a single IP, and you could block a ton of unaffiliated users by banning by IP.
– Angelo Schilling
Jan 18 at 23:11
|
show 9 more comments
8 Answers
8
active
oldest
votes
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]
answered Jan 16 at 15:52
Sean WerkemaSean Werkema
2,626239
52
Solid advice. Although I still call this locking accounts, it's just with a short timeout
– paj28
Jan 16 at 16:24
5
I agree with this for lock-and-forget implementations, but short-duration locks (automatically unlock again after a few minutes) can be useful for rate-limiting brute force attacks.
– Joel Coehoorn
Jan 16 at 16:46
12
But should you have a display that informs the user of how long the login delay will be for the next attempt?
– Yozarian22
Jan 16 at 21:54
5
@MichaelEricOberlin: Anecdotally, we had a case of one user with a constantly locked account. After many hours spent investigating, it turned out to be a coworker/nemesis of the user who kept doing it to spite the user. It wasn't on a company wide scale but it also doesn't quite require expert skills to lock out someone you want to.
– Flater
Jan 17 at 13:46
14
For an online system, doubling the lock-out time doesn't really help all that much. Being locked out with your whole IT department for a couple of days is anooying enough, but it's also not that hard to do repeat your attack at increasing intervals, still keeping your team locked out more or less indefinitely.
– Jasper
Jan 17 at 15:05
|
show 22 more comments
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.
answered Jan 16 at 9:24
SilverSilver
1,606620
6
You're looking for NIST Special Publication 800-63 which can normally be seen here (hotlinked to the relevant section): pages.nist.gov/800-63-3/sp800-63b.html#throttle Of course, because they took the special effort to put that server into maintenance mode instead of just walking away (grumble) then you'll have to use the Wayback Machine to see it right now: web.archive.org/web/20181223021935/https://pages.nist.gov/…
– Ruscal
Jan 16 at 16:08
1
What I like is to remember at least the last failed password (Hashes). And if the same one is used do not increase the fail counter. This greatly helps with misremembered or scripted clients to not regularly lock out the offender.
– eckes
Jan 16 at 23:56
If an attacker only has to guess 1000s of times to get your password than it is not a strong password.
– Qwertie
Jan 17 at 1:30
@Qwertie, I will change it to a more vague description ;)
– Silver
Jan 17 at 10:08
add a comment |
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.
answered Jan 19 at 1:26
jamesdlinjamesdlin
91769
add a comment |
To give another perspective on this: it doesn't matter for a skilled attacker.
How are online accounts compromised today typically1? 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.
answered Jan 16 at 13:50
Tom K.Tom K.
6,54732451
add a comment |
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.
answered Jan 16 at 8:22
Security BeastSecurity Beast
1143
add a comment |
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.
answered Jan 16 at 9:29
jfran3jfran3
716
I hadn't seen Silver's comment when I posted, but I would second the NIST guidelines as a good base to start with.
– jfran3
Jan 16 at 9:31
add a comment |
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.
answered Jan 16 at 13:32
HugoHugo
71638
add a comment |
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.
answered Jan 19 at 21:44
BrandhoutBrandhout
261
I'm a pentester. If I give the advice "limit login attempts" and the customer replies "prove that it's vulnerable", I would be annoyed. It is a matter of luck whether I can get in via this method. Do you want to rely on luck, or would you rather apply logic and discover that, indeed, if one of your users sets a bad password, and one attacker gets lucky, you are pwned? Therefore, I would be annoyed to have to prove it. Then, if I later hear that there was a silent lock-out (so you let me do the work, knowing it cannot succeed), I would feel like you doubly wasted my time.
– Luc
Jan 19 at 22:33
1
So you annoyed the pentester, now let's switch to user mode. I cannot get into my account even though I know it must be one of those five passwords. Now I have to go through other steps to recover my account. Later I discover that my password was correct, but that the system just did not let me in because of too many attempts. Instead of wasting time trying different passwords, and feeding the site more and more possible passwords (giving my passwords more exposure), it would have been very nice if the system could have just told me.
– Luc
Jan 19 at 22:36
Finally, let's look at the situation as an attacker. If I can create an account, I can try 100 incorrect attempts on my own account (1. do login attempt in Firefox; 2. copy as curl from developer toolbar; 3. use Bash one-liner:for i in {1..100}; do <Ctrl+V>; done) and then see if I can still login. Nope! So there is a lock-out in place. Now I create another account and write a similar script that does first one invalid attempt, then two, then three... and in between I check if I can still login. This all takes about five minutes. Hiding the retry count is not a significant hindrance.
– Luc
Jan 19 at 22:49
@Luc you right hiding the retry count is not a massive hurdle for a determined attacker, but it is a hurdle none the less.
– Brandhout
Jan 21 at 6:24
What I might not have made clear in my anecdote is that the accounts were silently locked for a short period of time so pentest finding was incorrect, which is why they were asked to prove it. The point was that silent locking an account is perfectly valid way of doing this, it actually is done in practice and it shows that is can add hindrance to your attacker. You completely right that there are trade offs to be made and that is not perfect security, but that is always the case.
– Brandhout
Jan 21 at 6:30
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "162"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f201566%2fis-displaying-remaining-password-retry-count-a-security-risk%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
8 Answers
8
active
oldest
votes
8 Answers
8
active
oldest
votes
active
oldest
votes
active
oldest
votes
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]
answered Jan 16 at 15:52
Sean WerkemaSean Werkema
2,626239
52
Solid advice. Although I still call this locking accounts, it's just with a short timeout
– paj28
Jan 16 at 16:24
5
I agree with this for lock-and-forget implementations, but short-duration locks (automatically unlock again after a few minutes) can be useful for rate-limiting brute force attacks.
– Joel Coehoorn
Jan 16 at 16:46
12
But should you have a display that informs the user of how long the login delay will be for the next attempt?
– Yozarian22
Jan 16 at 21:54
5
@MichaelEricOberlin: Anecdotally, we had a case of one user with a constantly locked account. After many hours spent investigating, it turned out to be a coworker/nemesis of the user who kept doing it to spite the user. It wasn't on a company wide scale but it also doesn't quite require expert skills to lock out someone you want to.
– Flater
Jan 17 at 13:46
14
For an online system, doubling the lock-out time doesn't really help all that much. Being locked out with your whole IT department for a couple of days is anooying enough, but it's also not that hard to do repeat your attack at increasing intervals, still keeping your team locked out more or less indefinitely.
– Jasper
Jan 17 at 15:05
|
show 22 more comments
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]
answered Jan 16 at 15:52
Sean WerkemaSean Werkema
2,626239
52
Solid advice. Although I still call this locking accounts, it's just with a short timeout
– paj28
Jan 16 at 16:24
5
I agree with this for lock-and-forget implementations, but short-duration locks (automatically unlock again after a few minutes) can be useful for rate-limiting brute force attacks.
– Joel Coehoorn
Jan 16 at 16:46
12
But should you have a display that informs the user of how long the login delay will be for the next attempt?
– Yozarian22
Jan 16 at 21:54
5
@MichaelEricOberlin: Anecdotally, we had a case of one user with a constantly locked account. After many hours spent investigating, it turned out to be a coworker/nemesis of the user who kept doing it to spite the user. It wasn't on a company wide scale but it also doesn't quite require expert skills to lock out someone you want to.
– Flater
Jan 17 at 13:46
14
For an online system, doubling the lock-out time doesn't really help all that much. Being locked out with your whole IT department for a couple of days is anooying enough, but it's also not that hard to do repeat your attack at increasing intervals, still keeping your team locked out more or less indefinitely.
– Jasper
Jan 17 at 15:05
|
show 22 more comments
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]
answered Jan 16 at 15:52
Sean WerkemaSean Werkema
2,626239
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]
answered Jan 16 at 15:52
Sean WerkemaSean Werkema
2,626239
answered Jan 16 at 15:52
Sean WerkemaSean Werkema
2,626239
answered Jan 16 at 15:52
Sean WerkemaSean Werkema
2,626239
answered Jan 16 at 15:52
Sean WerkemaSean Werkema
2,626239
2,626239
52
Solid advice. Although I still call this locking accounts, it's just with a short timeout
– paj28
Jan 16 at 16:24
5
I agree with this for lock-and-forget implementations, but short-duration locks (automatically unlock again after a few minutes) can be useful for rate-limiting brute force attacks.
– Joel Coehoorn
Jan 16 at 16:46
12
But should you have a display that informs the user of how long the login delay will be for the next attempt?
– Yozarian22
Jan 16 at 21:54
5
@MichaelEricOberlin: Anecdotally, we had a case of one user with a constantly locked account. After many hours spent investigating, it turned out to be a coworker/nemesis of the user who kept doing it to spite the user. It wasn't on a company wide scale but it also doesn't quite require expert skills to lock out someone you want to.
– Flater
Jan 17 at 13:46
14
For an online system, doubling the lock-out time doesn't really help all that much. Being locked out with your whole IT department for a couple of days is anooying enough, but it's also not that hard to do repeat your attack at increasing intervals, still keeping your team locked out more or less indefinitely.
– Jasper
Jan 17 at 15:05
|
show 22 more comments
52
Solid advice. Although I still call this locking accounts, it's just with a short timeout
– paj28
Jan 16 at 16:24
5
I agree with this for lock-and-forget implementations, but short-duration locks (automatically unlock again after a few minutes) can be useful for rate-limiting brute force attacks.
– Joel Coehoorn
Jan 16 at 16:46
12
But should you have a display that informs the user of how long the login delay will be for the next attempt?
– Yozarian22
Jan 16 at 21:54
5
@MichaelEricOberlin: Anecdotally, we had a case of one user with a constantly locked account. After many hours spent investigating, it turned out to be a coworker/nemesis of the user who kept doing it to spite the user. It wasn't on a company wide scale but it also doesn't quite require expert skills to lock out someone you want to.
– Flater
Jan 17 at 13:46
14
For an online system, doubling the lock-out time doesn't really help all that much. Being locked out with your whole IT department for a couple of days is anooying enough, but it's also not that hard to do repeat your attack at increasing intervals, still keeping your team locked out more or less indefinitely.
– Jasper
Jan 17 at 15:05
52
52
Solid advice. Although I still call this locking accounts, it's just with a short timeout
– paj28
Jan 16 at 16:24
Solid advice. Although I still call this locking accounts, it's just with a short timeout
– paj28
Jan 16 at 16:24
5
5
I agree with this for lock-and-forget implementations, but short-duration locks (automatically unlock again after a few minutes) can be useful for rate-limiting brute force attacks.
– Joel Coehoorn
Jan 16 at 16:46
I agree with this for lock-and-forget implementations, but short-duration locks (automatically unlock again after a few minutes) can be useful for rate-limiting brute force attacks.
– Joel Coehoorn
Jan 16 at 16:46
12
12
But should you have a display that informs the user of how long the login delay will be for the next attempt?
– Yozarian22
Jan 16 at 21:54
But should you have a display that informs the user of how long the login delay will be for the next attempt?
– Yozarian22
Jan 16 at 21:54
5
5
@MichaelEricOberlin: Anecdotally, we had a case of one user with a constantly locked account. After many hours spent investigating, it turned out to be a coworker/nemesis of the user who kept doing it to spite the user. It wasn't on a company wide scale but it also doesn't quite require expert skills to lock out someone you want to.
– Flater
Jan 17 at 13:46
@MichaelEricOberlin: Anecdotally, we had a case of one user with a constantly locked account. After many hours spent investigating, it turned out to be a coworker/nemesis of the user who kept doing it to spite the user. It wasn't on a company wide scale but it also doesn't quite require expert skills to lock out someone you want to.
– Flater
Jan 17 at 13:46
14
14
For an online system, doubling the lock-out time doesn't really help all that much. Being locked out with your whole IT department for a couple of days is anooying enough, but it's also not that hard to do repeat your attack at increasing intervals, still keeping your team locked out more or less indefinitely.
– Jasper
Jan 17 at 15:05
For an online system, doubling the lock-out time doesn't really help all that much. Being locked out with your whole IT department for a couple of days is anooying enough, but it's also not that hard to do repeat your attack at increasing intervals, still keeping your team locked out more or less indefinitely.
– Jasper
Jan 17 at 15:05
|
show 22 more comments
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.
answered Jan 16 at 9:24
SilverSilver
1,606620
6
You're looking for NIST Special Publication 800-63 which can normally be seen here (hotlinked to the relevant section): pages.nist.gov/800-63-3/sp800-63b.html#throttle Of course, because they took the special effort to put that server into maintenance mode instead of just walking away (grumble) then you'll have to use the Wayback Machine to see it right now: web.archive.org/web/20181223021935/https://pages.nist.gov/…
– Ruscal
Jan 16 at 16:08
1
What I like is to remember at least the last failed password (Hashes). And if the same one is used do not increase the fail counter. This greatly helps with misremembered or scripted clients to not regularly lock out the offender.
– eckes
Jan 16 at 23:56
If an attacker only has to guess 1000s of times to get your password than it is not a strong password.
– Qwertie
Jan 17 at 1:30
@Qwertie, I will change it to a more vague description ;)
– Silver
Jan 17 at 10:08
add a comment |
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.
answered Jan 16 at 9:24
SilverSilver
1,606620
6
You're looking for NIST Special Publication 800-63 which can normally be seen here (hotlinked to the relevant section): pages.nist.gov/800-63-3/sp800-63b.html#throttle Of course, because they took the special effort to put that server into maintenance mode instead of just walking away (grumble) then you'll have to use the Wayback Machine to see it right now: web.archive.org/web/20181223021935/https://pages.nist.gov/…
– Ruscal
Jan 16 at 16:08
1
What I like is to remember at least the last failed password (Hashes). And if the same one is used do not increase the fail counter. This greatly helps with misremembered or scripted clients to not regularly lock out the offender.
– eckes
Jan 16 at 23:56
If an attacker only has to guess 1000s of times to get your password than it is not a strong password.
– Qwertie
Jan 17 at 1:30
@Qwertie, I will change it to a more vague description ;)
– Silver
Jan 17 at 10:08
add a comment |
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.
answered Jan 16 at 9:24
SilverSilver
1,606620
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.
answered Jan 16 at 9:24
SilverSilver
1,606620
edited Jan 17 at 10:09
answered Jan 16 at 9:24
SilverSilver
1,606620
answered Jan 16 at 9:24
SilverSilver
1,606620
answered Jan 16 at 9:24
SilverSilver
1,606620
1,606620
6
You're looking for NIST Special Publication 800-63 which can normally be seen here (hotlinked to the relevant section): pages.nist.gov/800-63-3/sp800-63b.html#throttle Of course, because they took the special effort to put that server into maintenance mode instead of just walking away (grumble) then you'll have to use the Wayback Machine to see it right now: web.archive.org/web/20181223021935/https://pages.nist.gov/…
– Ruscal
Jan 16 at 16:08
1
What I like is to remember at least the last failed password (Hashes). And if the same one is used do not increase the fail counter. This greatly helps with misremembered or scripted clients to not regularly lock out the offender.
– eckes
Jan 16 at 23:56
If an attacker only has to guess 1000s of times to get your password than it is not a strong password.
– Qwertie
Jan 17 at 1:30
@Qwertie, I will change it to a more vague description ;)
– Silver
Jan 17 at 10:08
add a comment |
6
You're looking for NIST Special Publication 800-63 which can normally be seen here (hotlinked to the relevant section): pages.nist.gov/800-63-3/sp800-63b.html#throttle Of course, because they took the special effort to put that server into maintenance mode instead of just walking away (grumble) then you'll have to use the Wayback Machine to see it right now: web.archive.org/web/20181223021935/https://pages.nist.gov/…
– Ruscal
Jan 16 at 16:08
1
What I like is to remember at least the last failed password (Hashes). And if the same one is used do not increase the fail counter. This greatly helps with misremembered or scripted clients to not regularly lock out the offender.
– eckes
Jan 16 at 23:56
If an attacker only has to guess 1000s of times to get your password than it is not a strong password.
– Qwertie
Jan 17 at 1:30
@Qwertie, I will change it to a more vague description ;)
– Silver
Jan 17 at 10:08
6
6
You're looking for NIST Special Publication 800-63 which can normally be seen here (hotlinked to the relevant section): pages.nist.gov/800-63-3/sp800-63b.html#throttle Of course, because they took the special effort to put that server into maintenance mode instead of just walking away (grumble) then you'll have to use the Wayback Machine to see it right now: web.archive.org/web/20181223021935/https://pages.nist.gov/…
– Ruscal
Jan 16 at 16:08
You're looking for NIST Special Publication 800-63 which can normally be seen here (hotlinked to the relevant section): pages.nist.gov/800-63-3/sp800-63b.html#throttle Of course, because they took the special effort to put that server into maintenance mode instead of just walking away (grumble) then you'll have to use the Wayback Machine to see it right now: web.archive.org/web/20181223021935/https://pages.nist.gov/…
– Ruscal
Jan 16 at 16:08
1
1
What I like is to remember at least the last failed password (Hashes). And if the same one is used do not increase the fail counter. This greatly helps with misremembered or scripted clients to not regularly lock out the offender.
– eckes
Jan 16 at 23:56
What I like is to remember at least the last failed password (Hashes). And if the same one is used do not increase the fail counter. This greatly helps with misremembered or scripted clients to not regularly lock out the offender.
– eckes
Jan 16 at 23:56
If an attacker only has to guess 1000s of times to get your password than it is not a strong password.
– Qwertie
Jan 17 at 1:30
If an attacker only has to guess 1000s of times to get your password than it is not a strong password.
– Qwertie
Jan 17 at 1:30
@Qwertie, I will change it to a more vague description ;)
– Silver
Jan 17 at 10:08
@Qwertie, I will change it to a more vague description ;)
– Silver
Jan 17 at 10:08
add a comment |
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.
answered Jan 19 at 1:26
jamesdlinjamesdlin
91769
add a comment |
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.
answered Jan 19 at 1:26
jamesdlinjamesdlin
91769
add a comment |
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.
answered Jan 19 at 1:26
jamesdlinjamesdlin
91769
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.
answered Jan 19 at 1:26
jamesdlinjamesdlin
91769
edited Jan 21 at 3:27
answered Jan 19 at 1:26
jamesdlinjamesdlin
91769
answered Jan 19 at 1:26
jamesdlinjamesdlin
91769
answered Jan 19 at 1:26
jamesdlinjamesdlin
91769
91769
add a comment |
add a comment |
To give another perspective on this: it doesn't matter for a skilled attacker.
How are online accounts compromised today typically1? 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.
answered Jan 16 at 13:50
Tom K.Tom K.
6,54732451
add a comment |
To give another perspective on this: it doesn't matter for a skilled attacker.
How are online accounts compromised today typically1? 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.
answered Jan 16 at 13:50
Tom K.Tom K.
6,54732451
add a comment |
To give another perspective on this: it doesn't matter for a skilled attacker.
How are online accounts compromised today typically1? 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.
answered Jan 16 at 13:50
Tom K.Tom K.
6,54732451
To give another perspective on this: it doesn't matter for a skilled attacker.
How are online accounts compromised today typically1? 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.
answered Jan 16 at 13:50
Tom K.Tom K.
6,54732451
answered Jan 16 at 13:50
Tom K.Tom K.
6,54732451
answered Jan 16 at 13:50
Tom K.Tom K.
6,54732451
answered Jan 16 at 13:50
Tom K.Tom K.
6,54732451
6,54732451
add a comment |
add a comment |
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.
answered Jan 16 at 8:22
Security BeastSecurity Beast
1143
add a comment |
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.
answered Jan 16 at 8:22
Security BeastSecurity Beast
1143
add a comment |
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.
answered Jan 16 at 8:22
Security BeastSecurity Beast
1143
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.
answered Jan 16 at 8:22
Security BeastSecurity Beast
1143
answered Jan 16 at 8:22
Security BeastSecurity Beast
1143
answered Jan 16 at 8:22
Security BeastSecurity Beast
1143
answered Jan 16 at 8:22
Security BeastSecurity Beast
1143
1143
add a comment |
add a comment |
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.
answered Jan 16 at 9:29
jfran3jfran3
716
I hadn't seen Silver's comment when I posted, but I would second the NIST guidelines as a good base to start with.
– jfran3
Jan 16 at 9:31
add a comment |
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.
answered Jan 16 at 9:29
jfran3jfran3
716
I hadn't seen Silver's comment when I posted, but I would second the NIST guidelines as a good base to start with.
– jfran3
Jan 16 at 9:31
add a comment |
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.
answered Jan 16 at 9:29
jfran3jfran3
716
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.
answered Jan 16 at 9:29
jfran3jfran3
716
answered Jan 16 at 9:29
jfran3jfran3
716
answered Jan 16 at 9:29
jfran3jfran3
716
answered Jan 16 at 9:29
jfran3jfran3
716
716
I hadn't seen Silver's comment when I posted, but I would second the NIST guidelines as a good base to start with.
– jfran3
Jan 16 at 9:31
add a comment |
I hadn't seen Silver's comment when I posted, but I would second the NIST guidelines as a good base to start with.
– jfran3
Jan 16 at 9:31
I hadn't seen Silver's comment when I posted, but I would second the NIST guidelines as a good base to start with.
– jfran3
Jan 16 at 9:31
I hadn't seen Silver's comment when I posted, but I would second the NIST guidelines as a good base to start with.
– jfran3
Jan 16 at 9:31
add a comment |
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.
answered Jan 16 at 13:32
HugoHugo
71638
add a comment |
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.
answered Jan 16 at 13:32
HugoHugo
71638
add a comment |
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.
answered Jan 16 at 13:32
HugoHugo
71638
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.
answered Jan 16 at 13:32
HugoHugo
71638
answered Jan 16 at 13:32
HugoHugo
71638
answered Jan 16 at 13:32
HugoHugo
71638
answered Jan 16 at 13:32
HugoHugo
71638
71638
add a comment |
add a comment |
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.
answered Jan 19 at 21:44
BrandhoutBrandhout
261
I'm a pentester. If I give the advice "limit login attempts" and the customer replies "prove that it's vulnerable", I would be annoyed. It is a matter of luck whether I can get in via this method. Do you want to rely on luck, or would you rather apply logic and discover that, indeed, if one of your users sets a bad password, and one attacker gets lucky, you are pwned? Therefore, I would be annoyed to have to prove it. Then, if I later hear that there was a silent lock-out (so you let me do the work, knowing it cannot succeed), I would feel like you doubly wasted my time.
– Luc
Jan 19 at 22:33
1
So you annoyed the pentester, now let's switch to user mode. I cannot get into my account even though I know it must be one of those five passwords. Now I have to go through other steps to recover my account. Later I discover that my password was correct, but that the system just did not let me in because of too many attempts. Instead of wasting time trying different passwords, and feeding the site more and more possible passwords (giving my passwords more exposure), it would have been very nice if the system could have just told me.
– Luc
Jan 19 at 22:36
Finally, let's look at the situation as an attacker. If I can create an account, I can try 100 incorrect attempts on my own account (1. do login attempt in Firefox; 2. copy as curl from developer toolbar; 3. use Bash one-liner:for i in {1..100}; do <Ctrl+V>; done) and then see if I can still login. Nope! So there is a lock-out in place. Now I create another account and write a similar script that does first one invalid attempt, then two, then three... and in between I check if I can still login. This all takes about five minutes. Hiding the retry count is not a significant hindrance.
– Luc
Jan 19 at 22:49
@Luc you right hiding the retry count is not a massive hurdle for a determined attacker, but it is a hurdle none the less.
– Brandhout
Jan 21 at 6:24
What I might not have made clear in my anecdote is that the accounts were silently locked for a short period of time so pentest finding was incorrect, which is why they were asked to prove it. The point was that silent locking an account is perfectly valid way of doing this, it actually is done in practice and it shows that is can add hindrance to your attacker. You completely right that there are trade offs to be made and that is not perfect security, but that is always the case.
– Brandhout
Jan 21 at 6:30
add a comment |
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.
answered Jan 19 at 21:44
BrandhoutBrandhout
261
I'm a pentester. If I give the advice "limit login attempts" and the customer replies "prove that it's vulnerable", I would be annoyed. It is a matter of luck whether I can get in via this method. Do you want to rely on luck, or would you rather apply logic and discover that, indeed, if one of your users sets a bad password, and one attacker gets lucky, you are pwned? Therefore, I would be annoyed to have to prove it. Then, if I later hear that there was a silent lock-out (so you let me do the work, knowing it cannot succeed), I would feel like you doubly wasted my time.
– Luc
Jan 19 at 22:33
1
So you annoyed the pentester, now let's switch to user mode. I cannot get into my account even though I know it must be one of those five passwords. Now I have to go through other steps to recover my account. Later I discover that my password was correct, but that the system just did not let me in because of too many attempts. Instead of wasting time trying different passwords, and feeding the site more and more possible passwords (giving my passwords more exposure), it would have been very nice if the system could have just told me.
– Luc
Jan 19 at 22:36
Finally, let's look at the situation as an attacker. If I can create an account, I can try 100 incorrect attempts on my own account (1. do login attempt in Firefox; 2. copy as curl from developer toolbar; 3. use Bash one-liner:for i in {1..100}; do <Ctrl+V>; done) and then see if I can still login. Nope! So there is a lock-out in place. Now I create another account and write a similar script that does first one invalid attempt, then two, then three... and in between I check if I can still login. This all takes about five minutes. Hiding the retry count is not a significant hindrance.
– Luc
Jan 19 at 22:49
@Luc you right hiding the retry count is not a massive hurdle for a determined attacker, but it is a hurdle none the less.
– Brandhout
Jan 21 at 6:24
What I might not have made clear in my anecdote is that the accounts were silently locked for a short period of time so pentest finding was incorrect, which is why they were asked to prove it. The point was that silent locking an account is perfectly valid way of doing this, it actually is done in practice and it shows that is can add hindrance to your attacker. You completely right that there are trade offs to be made and that is not perfect security, but that is always the case.
– Brandhout
Jan 21 at 6:30
add a comment |
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.
answered Jan 19 at 21:44
BrandhoutBrandhout
261
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.
answered Jan 19 at 21:44
BrandhoutBrandhout
261
answered Jan 19 at 21:44
BrandhoutBrandhout
261
answered Jan 19 at 21:44
BrandhoutBrandhout
261
answered Jan 19 at 21:44
BrandhoutBrandhout
261
261
I'm a pentester. If I give the advice "limit login attempts" and the customer replies "prove that it's vulnerable", I would be annoyed. It is a matter of luck whether I can get in via this method. Do you want to rely on luck, or would you rather apply logic and discover that, indeed, if one of your users sets a bad password, and one attacker gets lucky, you are pwned? Therefore, I would be annoyed to have to prove it. Then, if I later hear that there was a silent lock-out (so you let me do the work, knowing it cannot succeed), I would feel like you doubly wasted my time.
– Luc
Jan 19 at 22:33
1
So you annoyed the pentester, now let's switch to user mode. I cannot get into my account even though I know it must be one of those five passwords. Now I have to go through other steps to recover my account. Later I discover that my password was correct, but that the system just did not let me in because of too many attempts. Instead of wasting time trying different passwords, and feeding the site more and more possible passwords (giving my passwords more exposure), it would have been very nice if the system could have just told me.
– Luc
Jan 19 at 22:36
Finally, let's look at the situation as an attacker. If I can create an account, I can try 100 incorrect attempts on my own account (1. do login attempt in Firefox; 2. copy as curl from developer toolbar; 3. use Bash one-liner:for i in {1..100}; do <Ctrl+V>; done) and then see if I can still login. Nope! So there is a lock-out in place. Now I create another account and write a similar script that does first one invalid attempt, then two, then three... and in between I check if I can still login. This all takes about five minutes. Hiding the retry count is not a significant hindrance.
– Luc
Jan 19 at 22:49
@Luc you right hiding the retry count is not a massive hurdle for a determined attacker, but it is a hurdle none the less.
– Brandhout
Jan 21 at 6:24
What I might not have made clear in my anecdote is that the accounts were silently locked for a short period of time so pentest finding was incorrect, which is why they were asked to prove it. The point was that silent locking an account is perfectly valid way of doing this, it actually is done in practice and it shows that is can add hindrance to your attacker. You completely right that there are trade offs to be made and that is not perfect security, but that is always the case.
– Brandhout
Jan 21 at 6:30
add a comment |
I'm a pentester. If I give the advice "limit login attempts" and the customer replies "prove that it's vulnerable", I would be annoyed. It is a matter of luck whether I can get in via this method. Do you want to rely on luck, or would you rather apply logic and discover that, indeed, if one of your users sets a bad password, and one attacker gets lucky, you are pwned? Therefore, I would be annoyed to have to prove it. Then, if I later hear that there was a silent lock-out (so you let me do the work, knowing it cannot succeed), I would feel like you doubly wasted my time.
– Luc
Jan 19 at 22:33
1
So you annoyed the pentester, now let's switch to user mode. I cannot get into my account even though I know it must be one of those five passwords. Now I have to go through other steps to recover my account. Later I discover that my password was correct, but that the system just did not let me in because of too many attempts. Instead of wasting time trying different passwords, and feeding the site more and more possible passwords (giving my passwords more exposure), it would have been very nice if the system could have just told me.
– Luc
Jan 19 at 22:36
Finally, let's look at the situation as an attacker. If I can create an account, I can try 100 incorrect attempts on my own account (1. do login attempt in Firefox; 2. copy as curl from developer toolbar; 3. use Bash one-liner:for i in {1..100}; do <Ctrl+V>; done) and then see if I can still login. Nope! So there is a lock-out in place. Now I create another account and write a similar script that does first one invalid attempt, then two, then three... and in between I check if I can still login. This all takes about five minutes. Hiding the retry count is not a significant hindrance.
– Luc
Jan 19 at 22:49
@Luc you right hiding the retry count is not a massive hurdle for a determined attacker, but it is a hurdle none the less.
– Brandhout
Jan 21 at 6:24
What I might not have made clear in my anecdote is that the accounts were silently locked for a short period of time so pentest finding was incorrect, which is why they were asked to prove it. The point was that silent locking an account is perfectly valid way of doing this, it actually is done in practice and it shows that is can add hindrance to your attacker. You completely right that there are trade offs to be made and that is not perfect security, but that is always the case.
– Brandhout
Jan 21 at 6:30
I'm a pentester. If I give the advice "limit login attempts" and the customer replies "prove that it's vulnerable", I would be annoyed. It is a matter of luck whether I can get in via this method. Do you want to rely on luck, or would you rather apply logic and discover that, indeed, if one of your users sets a bad password, and one attacker gets lucky, you are pwned? Therefore, I would be annoyed to have to prove it. Then, if I later hear that there was a silent lock-out (so you let me do the work, knowing it cannot succeed), I would feel like you doubly wasted my time.
– Luc
Jan 19 at 22:33
I'm a pentester. If I give the advice "limit login attempts" and the customer replies "prove that it's vulnerable", I would be annoyed. It is a matter of luck whether I can get in via this method. Do you want to rely on luck, or would you rather apply logic and discover that, indeed, if one of your users sets a bad password, and one attacker gets lucky, you are pwned? Therefore, I would be annoyed to have to prove it. Then, if I later hear that there was a silent lock-out (so you let me do the work, knowing it cannot succeed), I would feel like you doubly wasted my time.
– Luc
Jan 19 at 22:33
1
1
So you annoyed the pentester, now let's switch to user mode. I cannot get into my account even though I know it must be one of those five passwords. Now I have to go through other steps to recover my account. Later I discover that my password was correct, but that the system just did not let me in because of too many attempts. Instead of wasting time trying different passwords, and feeding the site more and more possible passwords (giving my passwords more exposure), it would have been very nice if the system could have just told me.
– Luc
Jan 19 at 22:36
So you annoyed the pentester, now let's switch to user mode. I cannot get into my account even though I know it must be one of those five passwords. Now I have to go through other steps to recover my account. Later I discover that my password was correct, but that the system just did not let me in because of too many attempts. Instead of wasting time trying different passwords, and feeding the site more and more possible passwords (giving my passwords more exposure), it would have been very nice if the system could have just told me.
– Luc
Jan 19 at 22:36
Finally, let's look at the situation as an attacker. If I can create an account, I can try 100 incorrect attempts on my own account (1. do login attempt in Firefox; 2. copy as curl from developer toolbar; 3. use Bash one-liner:
for i in {1..100}; do <Ctrl+V>; done) and then see if I can still login. Nope! So there is a lock-out in place. Now I create another account and write a similar script that does first one invalid attempt, then two, then three... and in between I check if I can still login. This all takes about five minutes. Hiding the retry count is not a significant hindrance.– Luc
Jan 19 at 22:49
Finally, let's look at the situation as an attacker. If I can create an account, I can try 100 incorrect attempts on my own account (1. do login attempt in Firefox; 2. copy as curl from developer toolbar; 3. use Bash one-liner:
for i in {1..100}; do <Ctrl+V>; done) and then see if I can still login. Nope! So there is a lock-out in place. Now I create another account and write a similar script that does first one invalid attempt, then two, then three... and in between I check if I can still login. This all takes about five minutes. Hiding the retry count is not a significant hindrance.– Luc
Jan 19 at 22:49
@Luc you right hiding the retry count is not a massive hurdle for a determined attacker, but it is a hurdle none the less.
– Brandhout
Jan 21 at 6:24
@Luc you right hiding the retry count is not a massive hurdle for a determined attacker, but it is a hurdle none the less.
– Brandhout
Jan 21 at 6:24
What I might not have made clear in my anecdote is that the accounts were silently locked for a short period of time so pentest finding was incorrect, which is why they were asked to prove it. The point was that silent locking an account is perfectly valid way of doing this, it actually is done in practice and it shows that is can add hindrance to your attacker. You completely right that there are trade offs to be made and that is not perfect security, but that is always the case.
– Brandhout
Jan 21 at 6:30
What I might not have made clear in my anecdote is that the accounts were silently locked for a short period of time so pentest finding was incorrect, which is why they were asked to prove it. The point was that silent locking an account is perfectly valid way of doing this, it actually is done in practice and it shows that is can add hindrance to your attacker. You completely right that there are trade offs to be made and that is not perfect security, but that is always the case.
– Brandhout
Jan 21 at 6:30
add a comment |
Thanks for contributing an answer to Information Security Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f201566%2fis-displaying-remaining-password-retry-count-a-security-risk%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
49
One consideration is that this can easily reveal whether a username exists on the site. This may be undesirable if user names are emails and the site is something personal like foot-fetish.com You can avoid this by returning a fake number for non-existent accounts
– paj28
Jan 16 at 16:25
11
Would it be so implausibly difficult for a hacker to count the number of failed attempts before receiving the locked account message? By this logic you should be asking whether displaying the "Account locked" message is a security risk.
– MonkeyZeus
Jan 16 at 16:51
3
@MonkeyZeus But with a number displayed the hacker knows when to stop before the account gets blocked and the failed attempt gets noticed. They then can wait some time until the owner logged in and resets the counter.
– BlackJack
Jan 16 at 17:45
5
Why has nobody considered that the retry count could be based on ip or device recognition?
– Nightwolf
Jan 17 at 8:34
10
no no no... do NOT lock out IPs for WEBSITE logins. SSH? Sure. But a lot of companies/schools/apartment complexes/hotels/etc NAT their entire internal space out through a single IP, and you could block a ton of unaffiliated users by banning by IP.
– Angelo Schilling
Jan 18 at 23:11