Failcount + Automatic Clearing and Brute Forcing

#1

Looking for some suggestions/help in regards to the failcounter and preventing brute forcing. It appears that after the failcounter clear timer completes, you can brute force the account.

For example, while testing I had my ‘Clear failcounter’ set to 5 minutes I performed the below actions.

  1. Entered my PIN wrong 5 times to hit my max fail.
  2. Tried to use my correct pin within the 5 minute window. This failed [expected]
  3. Waited 5 minutes
  4. Entered an invalid PIN several more times
  5. Entered the correct PIN immediately afterward and the authentication succeeded [unexpected]

I was assuming/hoping that any failed login attempt would reset the 5 minute timer. I may write a script in the event handler to do this, but I was checking to see if this was expected behavior or not first.

0 Likes

#2

This was in the official documentation, does it help?

1.17.16 How to mitigate brute force and lock tokens

For each failed authentication attempt privacyIDEA will increase a fail counter of a token. If the maximum allowed fail
counter is reached, authentication with this token is not possible anymore. Starting with version 2.20 the administrator
can define a timeout in minutes. The the last failed authentication is more than these specified minutes ago, a successful
authentication will reset the fail counter and access will be granted. See Automatically clearing Failcounter.
The failcounter avoids brute force attacks which guess passwords or OTP values. Choose a failcounter clearing timeout, which is not too long. Otherwise brute force would also lock the token of the user forever.
Another possibility to mitigate brute force is to define an authorization policy with the action
auth_max_fail. This will check, if there are too many failed authentication requests during the specified time
period. If there are, even a successful authentication will fail. This technique uses the audit log, to search for failed
authentication requests. See auth_max_fail.

0 Likes

#3

Not really. The problem is I don’t believe this is how the lockout should function. It basically means that as long as you wait for the initial lockout timer to clear, you can brute force any token.

The way something like Active Directory functions is that after an account is locked out and the duration passes, invalid attempts will lock out the account for the specified duration again.

Yes I could probably use the auth_max_fail policy to emulate something close, but then I still will run into the issue where help desk will not be able to unlock a token for a user. Because even if they reset the failcounter, the auth_max_fail will cause successful authentications to still fail.

What I would hope for would be the failcounter to do one of two things:

  1. ACTUALLY clear after the timeout completes and not psuedo-clear. If the failcounter actually reset to 0 after the timeout, then an additional set of failures would lockout the token for another set duration.
  2. While locked out, any invalid attempt would re-extend the lockout duration
0 Likes

#4

@droo, I think you are right. Can you please open an issue at github.
Thanks for insisting.

0 Likes

#5

I have opened an issue regarding this. I am also solving it myself for now by having a periodic task run to reset the failcounter on tokens that have surpassed the timeout.

0 Likes

#6

You can use this workaround: : https://www.privacyidea.org/reset-failcounter-using-event-handlers/

0 Likes