Regulation Rework

[james-d-elliott]

Description

Implement the following improvements to the regulator:

• Misc:
  • Add UI view for users
  • Add Password Reset Regulation (Feat: Password Reset Regulation #3859)
• Add 2FA Regulations:
  • Duo
  • Webauthn
  • TOTP (Both Failed Attempts and Successful Attempts)
• Add Modes:
  • Mode user only blocks the user (current functionality and the default)
  • Mode remote_ip only blocks the remote IP
  • Mode full blocks all (recommended mode)

Use Case

Enhances the regulation provider significantly.

Details

No response

Documentation

No response

Pre-Submission Checklist

• I agree to follow the Code of Conduct
• I have checked for related issues and checked the documentation

[JokerQyou]

If I understand correctly, this means by default if password reset or login failed in a row (say failed to 5 times), then this user is blocked from logging in for some time?
Wouldn't this open a door to some kind of DoS attack? I mean, by intentionally logging in with a correct username and an incorrect password, an attacker could indefinitely lock that user out.

[james-d-elliott]

This is of course technically possible. However weighing up the risks and benefits it's relatively easy to see the benefits here significantly outweigh the risks. This is also why incidentally we only have a very short lockout by default and are looking at giving users more policy options rather than "on" or "off".

The benefits here is the small invisible lockout reduces hashing costs associated with brute force attempts (another factor in the equation) and drastically impacts any attempt to utilize the web UI or API to brute-force a password, more than any other standard method except for the IP-based assuming the IP is correct (which as we've found rarely is due to misconfiguration of the reverse proxy when users don't follow the respective guide). The best overall policy will block both because brute forcing a known user could be distributed and this policy (if IP header is configured correctly) would substantially improve the chances they get a false negative (which is actually the best possible outcome aside from properly blocking them at the edge).

It should also be noted that there is no feedback (unless the username AND password are correct) that the username is valid, not even in execution time since it's profiled and a delay is imposed even if the username is wrong. Additionally there is no visible feedback that the lockout occurred on the frontend. As every setting is tunable, a person trying to leverage this would be unable to determine the interval to brute force, and would be restricted under normal conditions to a few bad attempts for a given period. As there are several existing mitigations preventing them from obtaining knowledge about the effectiveness of both of these avenues both of them are incredibly bad for actually producing reliable information. In fact most of the information in this instance should be considered unreliable.