[keycloak-dev] AbstractUsernameFormAuthenticator validateUserAndPassword process

[Ariel Carrera]

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.
The code focus on protect the username but forget to protect the password.

Example.
Username: admin
Pass: 1234
Brute force after 2 errors.

Step 1: user admin, pass 1 -> invalid user or pass
Step 2: user admin, pass 12 -> invalid user or pass
Step 3: user admin, pass 123 -> invalid user or pass (brute force not
apply, but is working now)
Step 4: user admin, pass 1234 -> temporary locked (password ok!!!, brute
force apply)
Bingo...you have the admin password
El 1/4/2016 4:48, "Marek Posolda" <mposolda at redhat.com> escribió:

> On 01/04/16 09:41, Marek Posolda wrote:
>
> On 31/03/16 18:17, Ariel Carrera wrote:
>
> 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.
> If you wants I can open a new jira issue to discuss about it.
>
> Hmm... I am missing the scenario where exactly is the security risk? Could
> you elaborate more? What I can see is:
>
> - 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)
>
> - 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"
>
> 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 :
> http://lists.jboss.org/pipermail/keycloak-dev/2016-March/006751.html
>
> Marek
>
>
> Marek
>
>
> 2016-03-31 7:44 GMT-03:00 Marek Posolda <mposolda at redhat.com>:
>
>> 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.
>>
>> Marek
>>
>>
>>
>> On 30/03/16 17:40, Ariel Carrera wrote:
>>
>> Hi, I am developing a Federation Provider, and I have a question...
>>
>> Why the method () checks if the user "is enabled" after validate the
>> password instead of before of the password validation?
>>
>> AbstractUsernameFormAuthenticator.validateUserAndPassword: line 141/151
>> ...
>>         if (invalidUser(context, user)){
>>             return false;
>>         }
>>
>> *        if (!validatePassword(context, user, inputData)){*
>> *            return false;*
>> *        }*
>>
>> *        if(!enabledUser(context, user)){*
>> *            return false;*
>> *        }*
>> ...
>>
>> If the user is disabled... why validate his password and return a
>> password validation error message?
>>
>> --
>> Ariel Carrera
>>
>>
>> _______________________________________________
>> keycloak-dev mailing listkeycloak-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>>
>>
>
>
> --
> Tatú
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160401/a520d5f3/attachment-0001.html