User Account Security: Account Lockout

The Goal

The aim of this knowledge base entry is to give guidance on how companies can improve the user account security with an account lockout feature, to prevent bruteforce attacks. We’ll cover ways to make account lockout effective as well as issues that lockout may unintentionally introduce.

Key Takeaways

• Understand how account lockout will improve the security of user accounts.
• Understand the problems that account lockout can introduce.
• Understand the different approaches to lockout, such as exponential backoff.
• Understand the different methods of unlocking accounts and their trade-offs.

The Trade Off

With account lockout there is a trade off between a user’s ability to access the system easily and the system’s security. If you lock accounts after a number of incorrect password attempts this could block attackers from performing password guessing attacks, but it could also block legitimate users from accessing the system who have simply, temporarily, forgotten their password.

In fact, an attacker may be able to leverage account lockout to cause a denial of service attack. By intentionally entering incorrect passwords for user accounts, in order to cause those accounts to be locked, it may be possible for an attacker to lock out every user from the system – effectively disabling that system.

What are we protecting against?

It’s critical when designing any secure system to ensure that user passwords cannot be easily guessed. Whilst some of this burden is on the user to select a strong password, systems should be designed in such a way as to minimise any risk should a user make a less than ideal password choice.

So, we’re protecting against “online password guessing” where the attacker is attempting to guess the user’s password directly against the login system itself (as opposed to trying to “crack” a password hash or similar offline attack).

We may also wish to address Credential Stuffing, where a list of credentials extracted from one compromised system, are entered into another system, to determine if a user has reused the password. Some anti-automation mechanisms can reduce the risk of these types of attacks, but account lockout based on a number of incorrect passwords being entered is unlikely to help – as the attacker is likely to only enter one password per user account.

Account Lockout: Unlocking Accounts

There are a few different ways of “unlocking” accounts once the account has been locked due to a number of incorrect passwords being set. There are generally three methods for unlocking accounts: time-based, user-based verification, and administrator-based.

Administrator-based Unlock

With “Fixed Attempts, Administrator-based Unlock” the system would lock the account after a fixed number of incorrect password attempts (for example, 5 bad passwords) and require the user to contact an administrator to unlock their account. This can be a very secure as the organisation could have a procedure built into the unlock process for the administrator to verify the identity of the user. There are several benefits to this method, the first being that it’s likely to entirely prevent any significant brute force attack and if the administrator correctly verifies the user’s identity, it’s likely to reduce the risk of social engineering attacks too. However, there is one major downside: Administrative overhead.

What if an attacker locks out a large number of user accounts? That’s likely a lot of work for the administrators to unlock all of those accounts. What if the attacker locks out all accounts including the administrators? Well, you’re probably going to have a bad day and either access your break glass accounts or learn very quickly why you should have considered creating break glass accounts. An attacker may lockout all accounts intentionally, in order to perform a disruption or “denial of service” attack.

User-based Unlock

With “Fixed Attempts, User-based Unlock” the system would lock the account after a fixed number of incorrect password attempts and require the user to perform some action to verify who they are in order to unlock the account. The benefit here is that there is less administrative overhead, however there’s a large amount of nuance here to ensure that the user-based unlock system is as secure as the primary authentication system.

For example, imagine a website where when you select the “I have forgotten my password” option, it presented you with a simple knowledge-based challenge such as:

“What is your mothers maiden name?” or “Do I drive a Toyota?”

These types of challenges are limited in scope and, between personal data exposed through social media websites and just a good guess on the part of the attacker, they are unlikely to offer a good level of security.

That doesn’t mean that user-based unlocking is insecure, it just requires some thought and some nuance. Generally speaking, the user’s identity should be verified out-of-band and the verification process should be as secure as the primary authentication mechanism (e.g. not vulnerable to brute force attacks).

One method could be to email the user a secret token to their registered email address and ensuring that the token cannot be guessed (e.g. it is long and randomly generated) thereby verifying that the request came from the user. Of course, this solution is imperfect, for example if the user had reused the same password between your system and their email system, then the token may be compromised directly – however, it offers a good balance between security and administrative overhead.

Time-based Unlock

With “Fixed Attempts, Time-based Unlock” the system would lock the account after a fixed number of incorrect password attempts (for example, 5 bad passwords) and unlock the account automatically after a set amount of time has passed – for example, the account could automatically unlock after 5 minutes.

The problem with this approach is that the lockout duration may be short enough that an attacker will simply wait-out the delay. Additionally, an attacker may combine this with knowledge of the target user to ensure that the attack is unlikely to be noticed.

For example, consider a system that locks after 5 incorrect attempts and unlocks after 5 minutes. If the attacker knows that the legitimate user is only active during office hours on work days, the attacker may perform a bruteforce attack during the weekend, to ensure the attack goes unnoticed by the user.

The attacker could simply attempt 5 passwords, if these are incorrect they could wait 5 minutes and then attempt 5 more passwords. This would allow the attacker to perform something in the region of 1,440 password attempts per day, over a few weekends this could turn into many thousands of attempts. Additionally, this is per account, meaning the attacker gets many thousands of attempts for each account. Whilst this is unlikely to crack very strong passwords, many of the common passwords that users actually choose in the real world would be extremely vulnerable.

Increasing the lockout duration does help, for example increasing the lockout duration to 30 minutes would drop this from 1,440 attempts per day to only 240 attempts per user account per day…but that’s still a lot.

However, we still have to consider the trade off with the legitimate user. If a legitimate user forgets their password and attempts several before getting the correct one, locking them out for 5 minutes is a frustration, but locking them out for 30 minutes is a long time for them to be sitting around waiting.

Exponential Backoff

There is a variation of the time-based unlock, commonly called an “Exponential Backoff”, this is an improvement on the time-based unlocking method described above where the Lockout Duration increases with every subsequent account lockout. For example, if the user locks their account once the Lockout Duration will be 5 minutes, but if they lock it a second time it will be 25 minutes, then 125 minutes. (Note: it’s likely a good idea to have a maximum lockout duration, otherwise you might find a user reporting to helpdesk that their account is locked for 181 million years as they kept trying passwords!)

The main benefit here is that it’s unlikely to negatively affect a legitimate user, because a legitimate user is unlikely to attempt more than a small number of password guesses before simply contacting an administrator for help, or utilising the Forgotten Password functionality.

However, a system like this could significantly reduce the number of passwords an attacker could guess in any reasonable timeframe, so it’s a significant improvement on the fixed account lockout duration approach discussed above.

Observation Window

Another common feature we see in systems is the “Observation Window”, for example this is seen within Activity Directory in the setting “Reset account lockout counter after”. This setting specifies an amount of time (in minutes) before the lockout counter resets.

For example, if you set the Lockout Threshold to 5 attempts and the Observation Window to 30 minutes, this means that an attacker can try 4 passwords every 30 minutes without locking the account out. That’s 192 passwords attempts per account, per day.

Although we see this configuration (Threshold: 5 attempts, Observation Window: 30, Lockout Duration: 30 minutes) on almost every infrastructure penetration test, likely thanks to it being Microsoft’s “Suggested Setting”, it is unlikely that there is any meaningful benefit to this setting.

Whilst it is true that a user may attempt three or four passwords before “taking a break” and coming back to the login attempt later on (thereby causing the counter to reset) and therefore login without locking their account – given that most systems that have this configuration set also have the Lockout Duration set to 30 minutes, it offers no meaningful benefit. The user could have attempted 5 passwords, waited for the lockout duration and then tried again. That said, we would expect most users in actuality, would simply, unintentionally cause the account to lock and then contact the IT Helpdesk anyway.

Therefore, in our experience this setting offers no benefit to any user other than the attacker. As it allows them to continuously perform 192 attempts per account per day without locking any account. We strongly recommend that the Observation Window is disabled, or at least set to a long duration such as 120 minutes, to reduce the benefit it gives to the attacker.

Anti-Automation

An alternative approach to locking accounts after an incorrect number of login attempts is performed, is to employ some type of anti-automation protection, such as a CAPTCHA. The intention here is that instead of locking an account after a fixed number of incorrect passwords, we simply prevent the attacker from automating the attack. So, whilst it’s entirely feasible for an attacker to manually sit and type passwords into the login box, they’re unlikely to get any significant number of password attempts in, without employing a lot of co-conspirators to also type passwords manually.

The main benefit of anti-automation techniques here though, is that they can also prevent Credential Stuffing attacks, where an attacker is not trying many passwords per user account but instead is trying a one password per user account. These attacks generally occur after another system is breached, and the attacker wants to determine if any users have reused passwords on other systems. Preventing any automated login attempts will significantly hamper these types of attack too.

The problem with anti-automation techniques such as CAPTCHAs is that they can have a negative impact on usability of the system. Put bluntly, users don’t like them. There is one simple way to combine account lockout with anti-automation protection whilst minimising the impact on the user – and that is simply to require a CAPTCHA be completed when a potential bruteforce attack has been detected.

Therefore, users will generally not be presented with a captcha and can log in with just their valid username and password. However, should another protection such as the exponential backoff described above be activated due to a potential attack, then a CAPTCHA is also required. With this implementation the benefit of hampering Credential Stuffing attacks is lost , but additional protections against online bruteforce attacks are gained, whilst reducing the impact on legitimate users.

Read More

• Akimbo: Strong Passwords
• OWASP: Blocking Bruteforce Attacks