Failed logins logging and locking accounts when using IAM for access control

Hello Ricky,

Thanks for the great idea, I gave it my vote as well.

I would advise against indefinite lockout durations though or even lockout durations in excess of 5 minutes or so. It is important to keep in mind what the goal of the lockout is and what the actual effect will be.

The obvious goal of this feature is to prevent attackers from being able to brute-force passwords by cycling through a large amount of potential passwords every second until they are in. A less obvious – but just as important – goal is to not lock the original user out of their own account through no doing of their own. Otherwise this feature changes from a security measure into a denial of service vulnerability. Note that it is much easier for an attacker to find valid usernames than it is to brute-force a password. Typically, knowing someone’s company email address is enough. They could start cycling through potential usernames/email addresses instead and just lock everyone out of the application.

If you allow a person to try 5 times and then lock the account for 5 minutes, you have lowered the effective brute-force rate to 1 password per minute. This is more than sufficient to counteract any brute-force attempts. Indicium Universal already does this by the way (6 attempts, 5 minute lockout) and therefore the Universal GUI does as well, but at the moment it is not configurable.

@Jeroen van den Belt when can we expect this to get into our product?

@Ricky In the upcoming 2022.2 release (somewhere in June) a lot of ideas will be implemented, unfortunately this is not one of them. At the moment I have no estimate when this idea will be planned.