search

privacyidea / privacyidea

:closed_lock_with_key: multi factor authentication system (2FA, MFA, OTP Server)
http://www.privacyidea.org
GNU Affero General Public License v3.0
1.51k stars 317 forks source link

Brute force mitigation #4128

Open cornelinux opened 1 week ago

cornelinux commented 1 week ago

Situation

CC: 174609

We are trying to add an attack mitigation.

We assume that the first factor (static password like the LDAP password) is compromized. This is unknown.

The goal would be

  1. to avoid that the attacker guesses the second factor (like TAN or OTP)
  2. identify an attack on the 2nd factor, thus realizing that the first factor seems to be compromized.

Ideas

Current situation: The fail counter is increased for the token. You can have the fail counter cleared after some minutes. https://privacyidea.readthedocs.io/en/latest/configuration/system_config.html#clear-failcounter-after-minutes

However, there are the following ideas:

  1. Increase the time, when the fail counter is cleared like: Clear it after 5 Minutes, then after 10 Minutes, then after 30 Minutes. Resulting in a longer time, in which the token is not usable. What should happend after the 30 minutes?

  2. Trigger actions like notifying the user, notifying the admin. Deleting the token... on each lock event oder clear event.

  3. Return certain information in the /validte/check response. Currently it is not clear

    • Return "Your token has been locked for 20 minutes" as response to the actual locking request --- this information would
    • Return "Your token is currently locked, due to excessive fails..." --- this could be seen by the legit user, but could also help the attacker.
hex-m commented 1 week ago

related: https://github.com/privacyidea/privacyidea/issues/3741