An attacker could try to brute force the token of a user. This is why privacyIDEA uses a failcounter that increases on each failed authentication request. If the failcounter reaches a maximum value, authentication requests are blocked.
Event handlers are really very flexible and provide you with a lot of possibilities, we did not think of, when we developed them. In this blog post we show you, how you can use event handlers to reset this failcounter.
To do so, we use two event handlers. The first one we call “Write Authentication” the second one “Reset Failcounter”.
First event handler to store the authentication date
The first event handler stores the date when the failcounter is allowed to be reset again. It does this on every authentication request. I.e. each authentication request pushes a blocked token forward in time. An attacker would increase this date of the token even while the token is blocked. (You could change this behavior by adding more logic to the event handler).
The event handler “Write Authentication” is a token handler and does not need any additional conditions. It is important that you provide a higher order to this event handler. In this case we set the “Order” to “2”.
The Actions of the event handler look like this:
This event handler sets a “tokeninfo” entry on each authentication request. The key of the tokeninfo is “allow_counter_reset”. The value is the current time (“{now}”) plus certain minutes. So this is a timestamp in the future, when the failcounter should be allowed to reset.
Second event handler to reset the failcounter
The second event hanlder is actually ment to reset the failcounter.
Note, that the order (priority) must have a lower value than the first event handler. This way this reset event hanlder gets executed before the event handler, that sets the timestamp!
The conditions of this event handler now check for the timestamp we set in the first event handler:
This event handler will trigger, if the token is locked (the failcounter has reached the maximum value) and the tokeninfo “allow_counter_reset” lies in the past. I.e. the specified minutes in the first event handler are actually over.
The action of this event handler simply resets the fail counter:
Effective behaviour
An authentication request, that occurs after the specified time will actually reset the failcounter. But since this event handler can only be executed after the authentication request, an authentication request with a valid OTP value will reset the failcounter, but it will not succeed, since the request has already been handled.
Thus a user has to authenticate twice to first unlock the token and then to actually successfully authenticate.
