-
-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Regulation Rework #4730
Comments
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? |
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. |
Description
Implement the following improvements to the regulator:
user
only blocks the user (current functionality and the default)remote_ip
only blocks the remote IPfull
blocks all (recommended mode)Use Case
Enhances the regulation provider significantly.
Details
No response
Documentation
No response
Pre-Submission Checklist
The text was updated successfully, but these errors were encountered: