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.

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

If you agree then I can create JIRA issue for this and provide PR. Vlastimil

On 27 November 2015 at 10:23, Vlastimil Elias <velias(a)redhat.com&gt; 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 > > 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. +1 To suggestion from Thomas - we should ask for password when updating email at least when recover password over email is enabled. 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev >

On 27 November 2015 at 10:23, Vlastimil Elias <velias(a)redhat.com <mailto:velias@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

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.

+1 To suggestion from Thomas - we should ask for password when updating email at least when recover password over email is enabled.

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

On 27 November 2015 at 12:16, Vlastimil Elias <velias(a)redhat.com <mailto:velias@redhat.com>> wrote: Hi, On 27.11.2015 11:45, Stian Thorgersen wrote: > > > On 27 November 2015 at 10:23, Vlastimil Elias <velias(a)redhat.com > <mailto:velias@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.

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(a)lists.jboss.org > <mailto:keycloak-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -- Vlastimil Elias Principal Software Engineer Developer Portal Engineering Team

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(a)redhat.com <mailto:velias@redhat.com>> wrote: On 27.11.2015 12:28, Stian Thorgersen wrote: > > > On 27 November 2015 at 12:16, Vlastimil Elias <velias(a)redhat.com > <mailto:velias@redhat.com>> wrote: > > Hi, > > On 27.11.2015 11:45, Stian Thorgersen wrote: >> >> >> On 27 November 2015 at 10:23, Vlastimil Elias >> <velias(a)redhat.com <mailto:velias@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(a)lists.jboss.org >> <mailto:keycloak-dev@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

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(a)redhat.com > <mailto:velias@redhat.com>> wrote: > > > > On 27.11.2015 12:28, Stian Thorgersen wrote: >> >> >> On 27 November 2015 at 12:16, Vlastimil Elias >> <<mailto:velias@redhat.com>velias@redhat.com >> <mailto:velias@redhat.com>> wrote: >> >> Hi, >> >> On 27.11.2015 11:45, Stian Thorgersen wrote: >>> >>> >>> On 27 November 2015 at 10:23, Vlastimil Elias >>> <<mailto:velias@redhat.com>velias@redhat.com >>> <mailto:velias@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(a)lists.jboss.org >>> <mailto:keycloak-dev@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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev