[keycloak-dev] denial-of-service (DoS)

Bill Burke bburke at redhat.com
Tue Feb 17 19:50:17 EST 2015


I'll add this to the conversation:

Any Internet based application is vulnerable to DoS and there are a lot 
of existing solutions to help, i.e. Fail2Ban or any mature firewall or 
loadbalancing technology.  I'm not convinced we need to implement 
anything for DoS as IMO, organizations will already have something in 
place for this kind of stuff.

I kind of feel the same way with Brute force password hacking detection. 
  There's existing mature solutions out there that can read logs for 
failures and update firewall and load balancer rules dynamically.

On 2/17/2015 7:16 PM, Bill Burke wrote:
>
>
> On 2/17/2015 2:54 PM, Michael Gerber wrote:
>> Hi all,
>>
>> It’s very easy to produce an out of memory. Just make thousand of requests to the login page with a huge state parameter.
>> Keycloak allocates a new ClientSessionEntity for each request and stores it with the given state parameter in a ConcurrentHashMap (if the MemUserSessionProvider is used).
>>
>> Do you think it is necessary to create a new ClientSessionEntity before the user is authenticated?
>
> Yes, the ClientSession stores information about the protocol used and
> information passed with the protocol.  State parameter and redirect URI
> has to be saved as it is revalidated when the client makes an access
> token request.
>
> BTW, there's a lot of other things that are worse for DoS.  Specifically
> if you put in recommended password hashing iterations (20K), you could
> eat up the CPU quite easily too.
>
>> Wouldn’t it be possible to pass all necessary information via URL parameters? Create a LoginToken similar to the IDToken, encrypt it with the realm private key, and add it to the url as parameter.
>>
>
> A better approach would be to limit the amount of concurrent login
> requests from a specific IP.
>
>
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com


More information about the keycloak-dev mailing list