[keycloak-dev] Cleanup of 'Change password' screen in Account app
Vlastimil Elias
velias at redhat.com
Fri Nov 27 07:30:15 EST 2015
On 27.11.2015 13:25, 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.
Yep, 401 matches best probably, but at least hint in some response
header should be cool, probably in WWW-Authenticate as it is mandatory
for 401 ;-) But this is the future, proper Keycloak server support is
necessary first ;-)
Vl.
>
> 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 <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
>>> <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
>
>
--
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/afd5fb4c/attachment.html
More information about the keycloak-dev
mailing list