[keycloak-dev] Brute force attack protection

[Stian Thorgersen]

We could do the sleep on the client side. We'd set a flag on the account saying it's disabled until some time in the future. If an account is locked we can display a page that says wait N seconds (or something), and after N seconds redirect redirect to login form using meta refresh.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, 17 March, 2014 1:06:39 PM
> Subject: Re: [keycloak-dev] Brute force attack protection
> 
> 
> 
> On 3/17/2014 5:38 AM, Stian Thorgersen wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Bill Burke" <bburke at redhat.com>
> >> To: keycloak-dev at lists.jboss.org
> >> Sent: Friday, 14 March, 2014 10:01:47 PM
> >> Subject: Re: [keycloak-dev] Brute force attack protection
> >>
> >> Ugh, seems that Captchas are easily broken too and also cause as much as
> >> 10% loss in leads/users.  I've seen suggestions of a combination of IP
> >> Address whitelists and blacklists per user and cross user.
> >>
> >>
> >> 1. If a user successfully logs in, add their IP address to the user's
> >> whitelist.
> >> 2. After X failed login attempts per user, set the User's notBefore to
> >> incrementally higher times on multiple failures.  The notBefore check is
> >> ignored for IP address on the user's whitelist.
> >>
> >> The problem I see with this approach is that the attacker's IP might be
> >> on the whitelist because of a proxy.  There's also the problem with a
> >> Gateway/Proxy screwing up the Server's idea of what the client IP is.  I
> >> know a Gateway/Proxy can set headers like "HTTP_X_FORWARDED_FOR".  I'm
> >> wondering if you can trust the Gateway/Proxy to remove
> >> "HTTP_X_FORWARDED_FOR" headers sent by the client itself.
> >
> > Wouldn't a blacklist be better? If a user fails to login from a certain IP
> > address N times add the IP to a blacklist?
> >
> > I can see a few issues with a whitelist:
> >
> > * Shared IP/NAT
> > * Public networks (anyone at a Starbucks is on the whitelist)
> > * Dynamic IP addresses (home broadband)
> >
> 
> Did a bit more research.
> 
> Blacklist has the same issues as a whitelist.  What I think I'm going to
> do is if there is a failure, wait to respond to the client for N
> seconds.  This let's successful logins immediately, but delays responses
> from a failure.  I'll also automatically wait N number of seconds if the
> last failure was not that far back.  (1 secs?  2 secs?)
> 
> This could cause a DoS, but could be mitigated greatly if we used Async
> HTTP.  Unfortunately, I believe EAP has a race condition with Async
> HTTP.  Need to find out if it was fixed.
> 
> We'll also keep a log of failures by IP that can be displayed in the
> admin console.  Allow the admin to create blacklists/whitelists.  Allow
> the admin to specify if headers like "X-Forwarded-For" can be trusted.
> Allow admins to set up blocks/warnings by country IP.
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>