-
Notifications
You must be signed in to change notification settings - Fork 154
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
Add support for anti-brute force #207
Comments
IMHO this should be primarily implemented by things like OSSEC and fail2ban, those tools can also be more effective at deploying countermeasures. Providing a paragraph in documentation that one of them should be set up would be quite good already. |
I solved this way: In my user_model:
` |
Would be good if it had something for this enabled by default. I solved this partially with flask limit. Also using real time black hole lists, and a CDN in front that has it's own security lists/WAF, and such... But still they get through. They are very, very sneaky (hundreds of proxy IPs, and using up all the attempts per ip for example). However, it depends on your user base. If your organization has 1000s of people on one ip address, then these blocks fail. With industrial NAT becoming more common in some parts of the world and with ipv4s having run out - this will only get worse. Still, it's probably worth enabling something by default. (ps. thanks lots for maintaining this!) |
OWASP https://github.com/OWASP/ASVS/blob/master/4.0/en/0x11-V2-Authentication.md#v21-password-security-requirements 2.2.1 talks about brute force mitigation:
Verify that no more than 100 failed attempts per hour is possible on a single account.
This can probably be implemented as part of tracking.
Could also add slowing down responses (but of course attacker can send multiple requests that would be handled by different threads).
Some good background: https://security.stackexchange.com/questions/85435/silently-limiting-login-attempts?rq=1
In particular - watch out for telling people an account is locked out since that relays info that the account/username is valid! (send email/SMS instead).
And this one: https://security.stackexchange.com/questions/74211/what-is-the-difference-between-login-throttling-and-temporary-account-lockout
NIST 5.2.2 - Unless otherwise specified in the description of a given authenticator, the verifier SHALL limit consecutive failed authentication attempts on a single account to no more than 100.
and then... When the subscriber successfully authenticates, the verifier SHOULD disregard any previous failed attempts for that user from the same IP address.
What is confusing in the NIST verbiage is the first sentence talks about 'account' the second talks about IP addresses.
The text was updated successfully, but these errors were encountered: