[keycloak-dev] Rate Limiting Logins

Bruno Oliveira da Silva bruno at abstractj.org
Mon Sep 5 17:33:36 EDT 2016


I believe it makes sense. The idea of having it on Keycloak is
tempting and challenging. Although, like you mentioned,
this is something that people can solve with Firewalls or IDS.

Implementing a rate limit can be really tricky, because all the common ways
of identifying an adversary can be beaten. For example, configure the max
number of requests per-client wouldn't stop the threat of DoS. People
still can make multiple requests through proxies.

There's an interesting reading on it[1]. In the article, Troy introduces
a rate-limit by IP address. It works, but quoting him "Someone could also
fire up a botnet and hammer it from different IPs all around the globe".


[1] - https://www.troyhunt.com/the-have-i-been-pwned-api-rate-limiting-and-commercial-use/

On 2016-09-05, Stian Thorgersen wrote:
> The brute force protection is there only to prevent guessing the password
> through a brute force attack. It's not there to stop DOS attacks. We don't
> have any rate limiting at the moment and I believe that's something that
> would be better introduced with a firewall / intrusion detection system.
>
> It's non-trivial to add, especially with the fact that a single client that
> invokes the direct grant login could have thousands of legitimate users. I
> don't think a simple implementation would be much value and not replace a
> full fledged firewall.
>
> What did you have in mind with regards to requirements? Ability to
> configure max number of requests per-client? Per-user?
>
> For the OOM the events endpoints supports pagination as well as date ranges
> which should prevent and OOM issue when querying it.
>
> On 2 September 2016 at 15:44, Cory Snyder <csnyder at iland.com> wrote:
>
> > Hey guys,
> >
> > We ran into an issue recently where a customer didn’t have a great
> > understanding of the OAuth2 authorization process and was submitting many
> > direct grant login requests per second. They were successfully
> > authenticating each time, so the brute force protection features don’t
> > apply. It basically ended up being a DOS issue. We also ended up having OOM
> > issues when trying to query the events for this customer during a scheduled
> > job that we use to build reports on login events. We’re still running 1.8.2
> > at the moment, so I’m wondering if you guys have implemented any kind of
> > rate limiting / DOS prevention that could have prevented this in one of the
> > later releases? If not, I'm proposing that it might be worth considering, I
> > could try to contribute something if you like. What do you guys think?
> >
> > Thanks,
> >
> > Cory Snyder
> >
> >
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >

> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


--

abstractj
PGP: 0x84DC9914


More information about the keycloak-dev mailing list