Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Proposal: prevent password guessing with rate limiting #1259
Certain compliance situations require us to prevent brute force password guessing for logins.
We would like SSP to have built in support (which we are proposing to write) for rate limiting authentication attempts.
Non proposed features:
Storing rate limiting data
We would use
Rate limiting algorithm
The two most common algorithms are either a leaky bucket approach or a fixed/sliding window.
In a leaky bucket approach, a given user or ip (or etc) would be given C authentication attempts and every minute could earn N more per minute (up to a maximum of C). This allows for bursty traffic patterns.
A window approach would allow N logins per time window.
I don't have a preference for algorithm. If SSP project does have a preference, please let me know. A fixed window is likely an easy algorithm
I've seen systems that alert the user to being locked out and ones that just always return "Invalid username/password" for locked out users. The former is more user friendly but would require template changes to display the new message (and require translation).
Initial proposal is just to say "Invalid username/password" while logging that the user/ip is locked out in the logs. If SSP project has a preference for better messaging, please let me know.
DoS protection with device cookies
The downside of any system that locks users or ips out after failed attempts is that they can be used to denial of service a user or IP. Device cookies help protect against this.
Describe alternatives you've considered
Finding an apache module to perform rate limiting.
I'm interested in opinions/suggestions/etc prior to us starting to work on this feature.
What's holding you back from creating an
A few thoughts on what I've just read:
I think, we should be able to come up with some of these enhancements, perhaps as traits, that can be easily be reused in custom authsources..
Nothing is holding us back from just creating our own. The goal was to make it available to classes that already extend
I must not have explained it very well. Subclasses wouldn't have to make any changes to take advantage of rate limiting. The hash alg and salt is just for configuring rate limiting based on password. The underlying password store doesn't need to know anything about it. It also doesn't need to be enabled for those that, understandably, don't want to rate limit based on password.
It will do us good :) The attacks we see are generally unsophisticated and just use a few IP addresses. Limiting on IP address is useful to us. For an attacker with a botnet with lots of IPs we'll rely on IP reputation and threat lists that get fed into our WAF.
I agree on optional. I also agree that they all require someplace to store the data. I don't know of way to perform rate limiting without storing data.
That's an interesting idea.
Just some things to consider.
Yup, that's why turning on IP rate limiting is optional, or you can white list your corporate IP.
The rate limiting is for the "enter username and password" form on the IdP side, so there is no assertion to decrypt. I agree an attacker that wants to overload your CPU has other vectors they can use.
That is a good point that I hadn't consider. The more things (user, ip, password, etc) you track to rate limit, the slower it will be. However for users logging in as themselves from a browser they have previously logged in with will have a device cookie. If the device cookie is valid (which is one check) and the user enters the correct password then they will get through with one read from the store. IMHO, the vast majority of legitimate traffic will fit that pattern.
FWIW, all our memcached calls are instrumented to time them and the vast majority take less than 10 ms.
I think this is a very good idea Patrick!
I agree that many users could benefit from this out of the box, if we implement it in the base class and you just need to add some configuration directives to it I see some difficult bits though:
We need to decide what do we want to protect from, since this could be used both to protect against (D)DoS or against brute forcing. The former needs mechanisms external to the software, in the servers or even the network. The latter is something we can tackle in the software. For that case, I see two approaches (not necessarily excluding each other) that could be interesting:
Does that sound interesting?
That is interesting idea to do it at that point, but as you pointed out there is the worry about side channel attacks with the timing or behavior. I suppose if we're going to do the checks regardless of authentication failure or success, then it wouldn't matter if it was before or after. In that case I think doing it prior to the authentication check could have some benefits, such as not passing known "bad" requests to the underlying password store where it could trigger additional problems (like AD lockout policies designed for internal connections).
I like that idea a lot. It reminds me of the PAM stack for unix logins.
For example, if a deployer of SSP wanted to show a captcha after 5 failed logins, and block for 10 minutes after 15 failed logins, what are you thinking pseudo code wise?
Or is there a chain of evaluators that create/define some structure that is passed to the callback?
Where would a deployer define their callback? Can that be done in
Or are you thinking something else?