<p dir="ltr">Hi marek, look at jira for more information. I sent a jira issue with the steps to reproduce the big security risk in Form authorization with "brute force detection". I had check grant validation and it is ok.<br>
The code focus on protect the username but forget to protect the password.</p>
<p dir="ltr">Example. <br>
Username: admin<br>
Pass: 1234<br>
Brute force after 2 errors.</p>
<p dir="ltr">Step 1: user admin, pass 1 -> invalid user or pass<br>
Step 2: user admin, pass 12 -> invalid user or pass<br>
Step 3: user admin, pass 123 -> invalid user or pass (brute force not apply, but is working now)<br>
Step 4: user admin, pass 1234 -> temporary locked (password ok!!!, brute force apply)<br>
Bingo...you have the admin password</p>
<div class="gmail_quote">El 1/4/2016 4:48, "Marek Posolda" <<a href="mailto:mposolda@redhat.com">mposolda@redhat.com</a>> escribió:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>On 01/04/16 09:41, Marek Posolda wrote:<br>
</div>
<blockquote type="cite">
<div>On 31/03/16 18:17, Ariel Carrera
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>Marek, that's makes sense, but, what happen when the user
is known by the attacker? If the brute force check is in the
"isEnabled" method (after password validation), the attacker
guesses the password successfully, the brute force
protection never apply. Please check the code because i am
afraid that it can be a big security risk.</div>
<div>If you wants I can open a new jira issue to discuss about
it.</div>
</div>
</blockquote>
Hmm... I am missing the scenario where exactly is the security
risk? Could you elaborate more? What I can see is:<br>
<br>
- In case that attacker knows both username and password of user,
the security is compromised anyway. In this case, Keycloak don't
have possibility to differ between valid user (who knows his
username and password) and attacker (who knows both username and
password). So in case that user is enabled, both valid user or
attacker are able to login. In case that user is disabled, both
valid user and attacker will receive message "Account is disabled"
(because "validatePassword" check passes, but "enabledUser" check
fails)<br>
<br>
- In case that attacker knows just username, the
"validatePassword" check will fail and will be "logged" in
BruteForce too. Attacker will receive message "Incorrect username
or password"<br>
</blockquote>
Also one more point, if user account is temporarily disabled because
of BruteForce protection, attacker won't recognize it because
message will still be "Incorrect username or password" . He won't
know that he guessed password. We added this recently, see some
related discussion here :
<a href="http://lists.jboss.org/pipermail/keycloak-dev/2016-March/006751.html" target="_blank">http://lists.jboss.org/pipermail/keycloak-dev/2016-March/006751.html</a><br>
<br>
Marek<br>
<blockquote type="cite"> <br>
Marek<br>
<br>
<blockquote type="cite">
<div class="gmail_extra"><br>
<div class="gmail_quote">2016-03-31 7:44 GMT-03:00 Marek
Posolda <span dir="ltr"><<a href="mailto:mposolda@redhat.com" target="_blank">mposolda@redhat.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>AFAIK one of the reasons is security. If an
attacker guesses username "foo", which exists, but not
password of user "foo", you don't want to tell him
that he successfully guessed username. So instead of
first checking that user "foo" is disabled and display
the message "The user account is disabled", you rather
check password first and then display the message
"Incorrect username or password", so attacker don't
have a clue if account really exists or password was
incorrect etc. Also if BruteForce protector is
enabled, you want to log the event as failed login, so
we're checking the password of user.<br>
<br>
Marek
<div>
<div><br>
<br>
<br>
On 30/03/16 17:40, Ariel Carrera wrote:<br>
</div>
</div>
</div>
<blockquote type="cite">
<div>
<div>
<div dir="ltr">
<div>
<div>Hi, I am developing a Federation
Provider, and I have a question...</div>
<div><br>
</div>
<div>Why the method () checks if the user "is
enabled" after validate the password instead
of before of the password validation?</div>
</div>
<div><br>
</div>
<div>AbstractUsernameFormAuthenticator.validateUserAndPassword:
line 141/151<br>
</div>
<div>...</div>
<div>
<div> if (invalidUser(context, user)){</div>
<div> return false;</div>
<div> }</div>
<div><br>
</div>
<div><b> if (!validatePassword(context,
user, inputData)){</b></div>
<div><b> return false;</b></div>
<div><b> }</b></div>
<div><br>
</div>
<div><b> if(!enabledUser(context,
user)){</b></div>
<div><b> return false;</b></div>
<div><b> }</b></div>
</div>
<div>...</div>
<div><br>
</div>
<div>If the user is disabled... why validate his
password and return a password validation
error message?<br>
</div>
<div><br>
</div>
<div>-- <br>
<div>Ariel Carrera</div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
</div>
</div>
<pre>_______________________________________________
keycloak-dev mailing list
<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
</blockquote>
<br>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div>Tatú</div>
</div>
</blockquote>
<br>
</blockquote>
<br>
</div>
</blockquote></div>