We recently discovered that one of our custom login pages doesn’t have an account lock out feature so I’m helping our Engineering team with the scope to change this. PCI says to lock out an account after 6 failed logins, and keep the account locked our for 30 minutes or until manually unlocked by an Admin. That part is easy enough to do.
The question is what we should tell the end user, or if at all. So I see a few options.
1. If their account is locked, at the next login tell the end user that their account has been locked, regardless of whether they passed in a valid password or not.
2. If their account is locked, at the next login tell the end user that their account has been locked, but ONLY if they pass in a valid password. Otherwise return a generic failed login message.
3. Always return a generic failed login when an account is locked. Use the same message that is used when a bad username or bad password is entered.
You want to avoid letting an attacker know whether they’ve found a valid account or not. Option 1 fails this requirement.
If an account is locked you also don’t want to let them know that they’ve found valid username/password combination. Otherwise they just wait 30 minutes and then get into the account. So this wouldn’t actually stop a brute force. Option 1 passes, but Option 2 fails this requirement.
That leaves option 3. It could potentially create more confusion for the end user and thus more work for the Admins/Customer Support. But it seems the most secure. However multiple other websites I’ve used do show custom locked out messages so this doesn’t seem to be the standard.
I’ve tried looking at OWASP and NIST and haven’t found much with regards to the specifics. I can sort of see a work around with Option 1, but it would require much more dev work and it’s a lot more complicated so I would like to avoid it.
Any other options I’ve missed? What do you prefer?