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(a)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(a)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@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/keycloak-dev
>
>
>
--
Tatú