[keycloak-dev] Cleanup of 'Change password' screen in Account app
Bill Burke
bburke at redhat.com
Fri Nov 27 10:13:56 EST 2015
Why would you need re-auth for REST or even browser clients? Doesn't
access token and refresh token timeouts handle this sort of thing?
On 11/27/2015 7:25 AM, Stian Thorgersen wrote:
> Hmm.. re-auth request for rest endpoints is even more tricky. I think a
> rest endpoint would just have to return a 401? Then it's up to the
> client to figure out that it needs to re-authenticate.
>
> On 27 November 2015 at 13:22, Vlastimil Elias <velias at redhat.com
> <mailto:velias at redhat.com>> wrote:
>
>
>
> On 27.11.2015 12:28, Stian Thorgersen wrote:
>>
>>
>> On 27 November 2015 at 12:16, Vlastimil Elias
>> <<mailto:velias at redhat.com>velias at redhat.com
>> <mailto:velias at redhat.com>> wrote:
>>
>> Hi,
>>
>> On 27.11.2015 11:45, Stian Thorgersen wrote:
>>>
>>>
>>> On 27 November 2015 at 10:23, Vlastimil Elias
>>> <<mailto:velias at redhat.com>velias at redhat.com
>>> <mailto:velias at redhat.com>> wrote:
>>>
>>> Hi,
>>>
>>> I have two proposals for cleanup of 'Change password'
>>> screen in Account
>>> app based on my experience with it:
>>>
>>> 1. remove Cancel button - it has no any meaning on this
>>> screen/form, it
>>> only reshowns form with empty fields. And also there is a
>>> bug,
>>> "Password" field is hidden when it is used, which makes
>>> whole form unusable.
>>>
>>>
>>> +1
>>
>> OK, I'm going to create JIRA and provide PR for this.
>>
>>>
>>> 2. remove validation of current password (remove
>>> "Password" field). Two
>>> reasons for this:
>>> - security impact of this check is small. If attacker
>>> is able to
>>> compromise Account app then he can always change email
>>> and then use
>>> "Forgot password" feature to change password
>>> - user created over Identity Provider do not know old
>>> password
>>> (because it is not set) so he is not able to set password
>>> using this screen
>>> After we implement support for reauthentication
>>> (KEYCLOAK-2076) then we
>>> should set some reasonable reauth timeout for Account app
>>> instead, this
>>> will make it more secure at all.
>>>
>>>
>>> -1 Reset password over email may not be enabled at all. We
>>> already allow setting password for IdPs login without
>>> requiring the existing password.
>> Fair enough
>>>
>>> +1 To suggestion from Thomas - we should ask for password
>>> when updating email at least when recover password over email
>>> is enabled.
>>
>> Makes sense, but what to do if user has no password set at
>> this point? Don't ask him, or reauthenticate him by other
>> available mechanism?
>>
>> And there are also other "dangerous" operations in Account
>> app. Eg. attacker who gains access to it can disable OTP
>> without any recheck. This should be protected too.
>> I believe whole Account app should be correctly protected by
>> reauthentications. Question is if implement it somehow
>> specifically in the app, or resolve this generally as part of
>> KEYCLOAK-2076.
>>
>>
>> Yep, you're right there's other dangerous operations as well.
>> Re-authentication sounds like the correct approach, rather than
>> requesting the password again. We could have two configurable
>> timeouts in account management console. One that requires re-auth
>> for anything (~30 min default), and another that requires re-auth
>> for sensitive operations (~5 min).
>>
>> One thing with re-auth is that if it happens when a user submits a
>> form, you then someone have to also remember the values of the
>> form. Currently account management is stateless.
>
> Yep, implementing reauthentication schemes correctly in client apps
> may be tricky, mainly for POST requests (and even worse posts with
> file upload) and AJAX call handlers etc.
> Beside Keycloak Account app we should try to provide reasonable
> support in Keycloak adapters, but it may be tricky as related Java
> EE specifications (JAAS subsystems, auth related things in Java
> Servlet and EJB spec ) do not count with these more complicated
> schemes too much.
>
> And I also thought if reauthentication scheme should be somehow
> implemented on REST API levels also.
> Eg. some REST endpoint operation will define that it needs reauth
> with some timeout. If client app call it with Bearer token then it
> should be able to tests last auth timestamp (which should be
> possible as it may be in the token as claim) and propagate back info
> that it needs reauth (how to map this to HTTP?). Support for this
> should be added to the framework like RestEasy then.
>
> Vl.
>
>>
>>
>> Vlastimil
>>
>>>
>>> It seems to be common practice to ask for current password
>>> when updating the existing password.
>>>
>>>
>>> If you agree then I can create JIRA issue for this and
>>> provide PR.
>>>
>>> Vlastimil
>>>
>>> --
>>> Vlastimil Elias
>>> Principal Software Engineer
>>> Developer Portal Engineering Team
>>>
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev at lists.jboss.org
>>> <mailto:keycloak-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>
>> --
>> Vlastimil Elias
>> Principal Software Engineer
>> Developer Portal Engineering Team
>>
>>
>
> --
> Vlastimil Elias
> Principal Software Engineer
> Developer Portal Engineering Team
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
More information about the keycloak-dev
mailing list