Hi,
To reduce maintance costs and to keep certain people out of our systems we would like to get more control on account logon auditing.
We like to have a certain set of features when IAM is used for access control.:
- To register failed logins (by logging this in IAM)
- In which it would be nice to get an IP-adress with that failed login. (reverse proxy headers)
- To set certain lockout threshold (i.e. #of failed logins)
- To lock accounts when failed logins are over said certain threshold (i.e. 3 failed logins and account is locked)
- To set the lockout duration (i.e. 15 minutes) where 0 = indefinite lockout
rgds, Ricky
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.