<div dir="ltr">You can also increase the number of owners for the cache which will mean that login failures will survive a single node restart.</div><div class="gmail_extra"><br><div class="gmail_quote">On 8 December 2015 at 16:15, Stian Thorgersen <span dir="ltr"><<a href="mailto:sthorger@redhat.com" target="_blank">sthorger@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">There's no assumption here that the server won't be restarted in production. However, when this was designed we decided it was good enough to store failed login attempts in memory. Reasoning behind that is we try to prevent changing users if possible. It's also good enough in our eyes as server restarts will be uncommon in production and it would be very unlikely that the server is restarted frequently enough for a brute force attack to succeed.<div><br>However, if this really isn't good enough for you then feel free to create a feature request asking for an option to be able to persist failed log-in attempts. We don't have resources to implement it at the moment though, so it would have to be a community contribution it you want it soon.</div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On 8 December 2015 at 15:29, Giovanni Baruzzi <span dir="ltr"><<a href="mailto:giovanni.baruzzi@syntlogo.de" target="_blank">giovanni.baruzzi@syntlogo.de</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div style="word-wrap:break-word;color:rgb(0,0,0);font-size:14px;font-family:Calibri,sans-serif"><pre><div>The question of Mara was perfectly legitimated and the answers are not really acceptable.</div></pre><pre>I have the opinion that the number of failures needs to be persisted and the designer should not make assumption about the times and periods for server restarts</pre><pre>Secondly, where should be such a brute detection implemented if not in Keycloak?</pre><pre>In effect is is implemented, but the implementation can be made better.</pre><pre>FYI information we implemented it using the functionalities of the LDAP server.</pre><pre><br></pre><pre>Regards,</pre><pre>Giovanni</pre><pre><br></pre><pre><br></pre><pre>>>In addition, is pretty much possible to configure fail2ban to read the
>>log files and store it into the database for example
>>(<a href="http://www.fail2ban.org/wiki/index.php/Commands#DATABASE" target="_blank">http://www.fail2ban.org/wiki/index.php/Commands#DATABASE</a>).
>>
>>I can be wrong, but I don't think Keycloak should have something like this.
>>
On Fri, Dec 4, 2015 at 5:26 PM, Stan Silvert <<a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">ssilvert at redhat.com</a>> wrote:
><i> On 12/4/2015 12:15 PM, Notarnicola, Mara wrote:
</i>><i>
</i>><i> Dear all,
</i>><i>
</i>><i> I have enabled brute force detection on my keycloak application server.
</i>><i>
</i>><i> I used keycloak 1.5.0 Final version.
</i>><i>
</i>><i> After several trials I saw that the number of failures of the users are
</i>><i> saved in session, so if the server will be restarted the counter starts from
</i>><i> 0 again.
</i>><i>
</i>><i> Why you don’t save it into db?
</i>><i>
</i>><i> I didn't design this, but I think it's because brute force detection is
</i>><i> designed to thwart guessing of credentials over a relatively short time
</i>><i> period. In production you don't restart the server very often.
</i>><i>
</i>><i>
</i>><i>
</i>><i> Mara
</i>><i>
</i>><i>
</i>><i>
</i>><i> _______</i></pre></div>
<br></div></div>_______________________________________________<br>
keycloak-user mailing list<br>
<a href="mailto:keycloak-user@lists.jboss.org" target="_blank">keycloak-user@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br></blockquote></div><br></div>
</blockquote></div><br></div>