What are the security practice or case studies for account lockouts?

Question

We have a platform where users can sign up for free using their email addresses (they can also associate social media account). Other than the name, email and social account there no other personal information is held about the customer. There is a possibility that the user account may be compromised through brute force attack by bots. Please keep in mind that we also do not want to discourage legitimate user experience.

Scope
What are the best practices or case studies around the platform on

1. How many attempts before locking out an account, and
2. duration of account lockout (linear or exponential based on the number of further retries).

Out of scope: Strong password

Answer 1

There are a couple of ways that the passphrase could be compromised by an automated attacker, which of course does not apply to the social media login. I ignore application-level vulnerabilities. You need to threat model these for all the ways that users can access the data: web and any APIs presented. Often APIs will use an identification token which is really just a string, which has obvious implications.

A dictionary or brute-force against a known user ID. Where an attacker tries many passphrases against a known user ID.

A known passphrase against brute-forced user ID. Where an attacker tries the same passphrase against the set of user IDs. This is particularly an issue if the user IDs are sequential or easily guessed.

You have some defences against these.

• Login throttling. Many web frameworks have this or can implement it: for example Django-Axes link
• For a given UID limit the number of attempts. Fewer than a dozen, then prevent access for a minute. All you want to do is increasing the work effort to run the cracker For a known password attack then you can check for enumerated accounts. You'll have to identify the attacker for which the IP address is a reasonable proxy or you can use browser finger printing or possibly use cookies.
• A CAPTCHA could work for your users. They are fairly intrusive so you could do what Amazon does and only show the CAPTCHA if there have been X failed attempts. Then you do not incommode your users. If you choose to use Google's reCaptcha then you have to deal with the fact that you are delegating to Google and the reCaptcha is really a check that the user has a Google account: it's perfidious IMHO. You could throw a simple "what is 1 +1" or whatever check.
• Blacklist source IP addresses that have too many failed attempts. But you will need to consider in your threat model that many people may come from a shared IP, for example anyone who works for company X may be behind the company firewall so you can't simply use IP address. Blacklisting is a great DOS that a malicious actor can use against you to block off access to your users. You will need to think about that in your threat model and ensure that your blacklist algorithms account for this. Eg if you have lots of users from university X and one person runs a brute force then you are going to shut off all your legitimate users if you are incautious in your defences.
• Web Application Firewall. Apache ModSecurity could be your friend, or a commercial variant Bash script to update IPTables based on X failed attempts from address Y
• As a variant to CAPTCHA send a one time code / link to their email address. The account is locked until the click on the link, which resets their password.

How many attempts before locking out an account, and

Allow five attempts for the same UID, same IP and different password. On the fourth attempt throw up a CAPTCHA or tell them you are going to email them a one time password valid for X minutes. On the seventh attempt with a valid CAPTCHA lock the account for 1 minute. Repeat and double the lockout each time. A legit user will have given up by this point and will have requested a new password. Give them the choice to reset password via email link. You need at least five because the first wrong password is wrong, the second is the same password typed more slowly, then the third, then they add 1 and then 2 to the password and finally give up.

Having a periodic 2 step authentication code sent to email can be a good mitigation. As NIST and NCSC both recommend not having periodic password changes then that still introduces some control.

Answer 2

This is a case where user experience and security need to align. You want to help your users to be secure by using good policies on the back end, but you do not want to annoy your users.

For a company, employee account settings are usually something in the range of:

10 login failures in 10 minutes resulting in a lockout of 10 minutes

The numbers go up and down by 5, depending on the company.

But this policy assumes that there is:

• a help desk to get the employee back working
• monitoring in place to detect if a bigger attack is going on

A small website really cannot provide this for customers.

So, you need to look at a policy that reflects the nature of your site, the nature of your users, and what is going to provide enough account security without it being an annoyance to either you or your users.

One big annoyance is someone locking out a user's account. If you cannot handle that situation, then your users are going to get locked out a lot.

Try looking at alternatives to account lockouts, like providing 2FA, or blocking the IPs of sources that have high numbers of login failures.