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.
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ú