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