[keycloak-dev] Brute force attack protection

[Bill Burke]

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