<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I think it’s the responsibility of the UserFederationProvider to decide if a password is valid or not. Therefore, even empty passwords have to be send to it.<div class=""><div apple-content-edited="true" class=""><br class="Apple-interchange-newline">
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On 23.11.2015, at 09:04, Stian Thorgersen &lt;<a href="mailto:sthorger@redhat.com" class="">sthorger@redhat.com</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Question: a user passing an empty password is that really a brute force attempt? Is it not more likely that a user has forgotten to enter the password? I'm asking because I'm not convinced forgetting to enter a value in the password field should count as a login attempt.</div><div class="gmail_extra"><br class=""><div class="gmail_quote">On 23 November 2015 at 09:02, Marek Posolda <span dir="ltr" class="">&lt;<a href="mailto:mposolda@redhat.com" target="_blank" class="">mposolda@redhat.com</a>&gt;</span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Sure, that would be fine. But again, it's important that with default<br class="">
settings, LDAPOperationManager.authenticate won't automatically<br class="">
authenticate AD users with empty password (which may happen when<br class="">
anonymous bind is enabled on AD side).<br class="">
<span class="HOEnZb"><font color="#888888" class=""><br class="">
Marek<br class="">
</font></span><div class="HOEnZb"><div class="h5"><br class="">
On 20/11/15 18:22, Michael Gerber wrote:<br class="">
&gt; We’ve got a custom UserFederationProvider, which authenticate users against an AD or DB. Therefore, we need to know if a user entered an empty password.<br class="">
&gt; I will create a PR and jira ticket for that, ok?<br class="">
&gt;<br class="">
&gt;&gt; On 20.11.2015, at 17:50, Marek Posolda &lt;<a href="mailto:mposolda@redhat.com" class="">mposolda@redhat.com</a>&gt; wrote:<br class="">
&gt;&gt;<br class="">
&gt;&gt; That will be the easiest path to use our BruteForceProtector.<br class="">
&gt;&gt;<br class="">
&gt;&gt; However AD also has some "BruteForceProtector" of it's own, which disables user in AD when he reach some count of invalid attempts. And I guess Michael wants to use that one and disable user in AD as well.<br class="">
&gt;&gt;<br class="">
&gt;&gt; Marek<br class="">
&gt;&gt;<br class="">
&gt;&gt; On 20/11/15 17:40, Bill Burke wrote:<br class="">
&gt;&gt;&gt; You can I guess, but why does it matter?&nbsp; invalidPassword hits the brute<br class="">
&gt;&gt;&gt; force detector if it is turned on.<br class="">
&gt;&gt;&gt;<br class="">
&gt;&gt;&gt; On 11/20/2015 10:16 AM, Michael Gerber wrote:<br class="">
&gt;&gt;&gt;&gt; AbstractUsernameFormAuthenticator.validatePassword<br class="">
&gt;&gt;&gt;&gt;<br class="">
&gt;&gt;&gt;&gt; public boolean validatePassword(AuthenticationFlowContext context, UserModel user, MultivaluedMap&lt;String, String&gt; inputData) {<br class="">
&gt;&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp;List&lt;UserCredentialModel&gt; credentials =new LinkedList&lt;&gt;();<br class="">
&gt;&gt;&gt;&gt; String password = inputData.getFirst(CredentialRepresentation.PASSWORD);<br class="">
&gt;&gt;&gt;&gt; if (password ==null || password.isEmpty()) {<br class="">
&gt;&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;invalidPassword(context, user);<br class="">
&gt;&gt;&gt;&gt; return false;<br class="">
&gt;&gt;&gt;&gt; }<br class="">
&gt;&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp;credentials.add(UserCredentialModel.password(password));<br class="">
&gt;&gt;&gt;&gt; boolean valid = context.getSession().users().validCredentials(context.getRealm(), user, credentials);<br class="">
&gt;&gt;&gt;&gt; if (!valid) {<br class="">
&gt;&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;invalidPassword(context, user);<br class="">
&gt;&gt;&gt;&gt; return false;<br class="">
&gt;&gt;&gt;&gt; }<br class="">
&gt;&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp;return true;<br class="">
&gt;&gt;&gt;&gt; }<br class="">
&gt;&gt;&gt;&gt;<br class="">
&gt;&gt;&gt;&gt; I think we can remove the first if (password == null || password.isEmpty())<br class="">
&gt;&gt;&gt;&gt;<br class="">
&gt;&gt;&gt;&gt; Am 20. November 2015 um 16:11 schrieb Bill Burke &lt;<a href="mailto:bburke@redhat.com" class="">bburke@redhat.com</a>&gt;:<br class="">
&gt;&gt;&gt;&gt;<br class="">
&gt;&gt;&gt;&gt;&gt; Point me to the code?<br class="">
&gt;&gt;&gt;&gt;&gt;<br class="">
&gt;&gt;&gt;&gt;&gt; On 11/20/2015 9:04 AM, Michael Gerber wrote:<br class="">
&gt;&gt;&gt;&gt;&gt;&gt; Hi All,<br class="">
&gt;&gt;&gt;&gt;&gt;&gt;<br class="">
&gt;&gt;&gt;&gt;&gt;&gt; keycloak does not pass an empty password to the validCredentials method<br class="">
&gt;&gt;&gt;&gt;&gt;&gt; in the UserFederationProvider class.<br class="">
&gt;&gt;&gt;&gt;&gt;&gt; Is there a reason for that? I would like to authenticate against an AD<br class="">
&gt;&gt;&gt;&gt;&gt;&gt; even if the password is empty, otherwise the user won't be blocked after<br class="">
&gt;&gt;&gt;&gt;&gt;&gt; x attempts.<br class="">
&gt;&gt;&gt;&gt;&gt;&gt;<br class="">
&gt;&gt;&gt;&gt;&gt;&gt; Michael<br class="">
&gt;&gt;&gt;&gt;&gt;&gt;<br class="">
&gt;&gt;&gt;&gt;&gt;&gt;<br class="">
&gt;&gt;&gt;&gt;&gt;&gt; _______________________________________________<br class="">
&gt;&gt;&gt;&gt;&gt;&gt; keycloak-dev mailing list<br class="">
&gt;&gt;&gt;&gt;&gt;&gt; <a href="mailto:keycloak-dev@lists.jboss.org" class="">keycloak-dev@lists.jboss.org</a> &lt;mailto:<a href="mailto:keycloak-dev@lists.jboss.org" class="">keycloak-dev@lists.jboss.org</a>&gt;<br class="">
&gt;&gt;&gt;&gt;&gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank" class="">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br class="">
&gt;&gt;&gt;&gt;&gt;&gt;<br class="">
&gt;&gt;&gt;&gt;&gt; --<br class="">
&gt;&gt;&gt;&gt;&gt; Bill Burke<br class="">
&gt;&gt;&gt;&gt;&gt; JBoss, a division of Red Hat<br class="">
&gt;&gt;&gt;&gt;&gt; <a href="http://bill.burkecentral.com/" rel="noreferrer" target="_blank" class="">http://bill.burkecentral.com</a><br class="">
&gt;&gt;&gt;&gt;&gt; _______________________________________________<br class="">
&gt;&gt;&gt;&gt;&gt; keycloak-dev mailing list<br class="">
&gt;&gt;&gt;&gt;&gt; <a href="mailto:keycloak-dev@lists.jboss.org" class="">keycloak-dev@lists.jboss.org</a> &lt;mailto:<a href="mailto:keycloak-dev@lists.jboss.org" class="">keycloak-dev@lists.jboss.org</a>&gt;<br class="">
&gt;&gt;&gt;&gt;&gt; <a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank" class="">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br class="">
<br class="">
_______________________________________________<br class="">
keycloak-dev mailing list<br class="">
<a href="mailto:keycloak-dev@lists.jboss.org" class="">keycloak-dev@lists.jboss.org</a><br class="">
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank" class="">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br class="">
</div></div></blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></div></body></html>