0

I am starting to implement an exponential backoff system to lockout accounts after a certain amount of failed attempts (1min after 5 fails, 2min after 10 fails, etc.). However, as this source suggests, attackers can detect account existence, using the fact that only legitimate accounts are locked after too many failed attempts.

My fix would be to also lockout non-existent accounts, by keeping a list of accounts name with number of failed attempts, reset regularly. This way the system will not reveal any information about accounts existence. Does this seems like a good solution?

If not, what would you suggest?

Improve this question
3
  • 2
    Account Lockout's are a really bad thing, unless you are absolutely certain that the mere possibility of account compromise is by far more tragic than the certainty that an account will not be available to the customer. In 99.99999% of all cases, this is not correct.
    – user163495
    Feb 3, 2020 at 15:28
  • I meant to use an exponential account locking (1min, then 2min, then 5min, etc.). Do you also recommend not using this kind of restriction? I will update the question with this precision. Thanks!
    – Racater
    Feb 3, 2020 at 15:34
  • I definitely agree with @MechMK1. While a temporary account lockout may slow down an attacker, it also locks out legitimate users, becoming a serious threat of DoS. If an attacker wants to stop a particular user from using your service, they can easily keep the account permanently locked. Also, this doesn't help against password spraying, which is an increasingly common type of attack. In short, account lockouts are too broad of a tool - they do too much damage without providing enough security.
    – Conor Mancone
    Feb 3, 2020 at 15:42

1 Answer 1

Reset to default
2

Account Lockouts can be a bad idea

Imagine you have the user bob, who has an account at your awesome service. Now Eve wants to be malicious, and lock Bob out of his account.

She sends an invalid login request, then another, then another, and repeats that process until she receives the message that the account bob is locked for a while. Then she repeats this process again and again, until bob is locked for all eternity.

Bob on the other hand would like to log into your awesome service, and gets a confusing error message that his account is locked. He contacts your support at your expense, and they inform him that there has been malicious activity (and helpfully advise him to scan his computer using anti-virus software). After Bob has wasted half an hour of his time, he attempts to log in again, only to find that Eve has still locked his account.

You might ask why on earth Eve would do that. The motive can be manifold:

  • Blackmail (give me money to get your account back)
  • for teh lulz
  • Getting Bob to use Eve's even more awesome service instead
  • etc...

How to do it instead

What you really want to prevent is online brute-forcing through automated means. Instead of locking the account, consider using a CAPTCHA to verify a human on the other end of the connection. You could also slow-down responses to login attempts to several seconds. This way, Bob would only have to wait a few seconds instead of not being allowed to log in at all.

If you want to go really big and fancy, try to do some behaviour analysis. This will cost you big time, but it does prove to be a useful aid when trying to determine if a login attempt is potentially malicious or not.

What about non-existent accounts?

So far, I explained why account lockouts are a bad idea. But if you really really have to implement them (e.g. because of customer demand), then you should also "lock" non-existent accounts.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .