[keycloak-dev] Cleanup of 'Change password' screen in Account app

[Stian Thorgersen]

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> wrote:

>
>
> On 27.11.2015 12:28, Stian Thorgersen wrote:
>
>
>
> On 27 November 2015 at 12:16, Vlastimil Elias < <velias at redhat.com>
> velias at redhat.com> wrote:
>
>> Hi,
>>
>> On 27.11.2015 11:45, Stian Thorgersen wrote:
>>
>>
>>
>> On 27 November 2015 at 10:23, Vlastimil Elias < <velias at redhat.com>
>> 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
>>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20151127/2e998afe/attachment-0001.html