From: "Michael Gerber" <gerbermichi(a)me.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; Sent: Monday, 26 January, 2015 4:23:49 PM Subject: Re: [keycloak-dev] Looking for a workaround... > ----- Original Message ----- >> From: "Michael Gerber" <gerbermichi(a)me.com&gt; >> To: "Stian Thorgersen" <stian(a)redhat.com&gt; >> Sent: Monday, January 26, 2015 2:10:59 PM >> Subject: Re: [keycloak-dev] Looking for a workaround... >> ----- Original Message ----- >> From: "Michael Gerber" <gerbermichi(a)me.com&gt; >> To: keycloak-dev(a)lists.jboss.org >> >> Sent: Monday, January 26, 2015 1:37:53 PM >> Subject: [keycloak-dev] Looking for a workaround... >> Hi all, >> I receive a lot of bug reports from our test team because of the following >> two issues: >> - Reset password leads to 400 Bad Request ( >> https://issues.jboss.org/browse/KEYCLOAK-1014 ) >> This is a tricky one - we can't ignore the state variable as that would >> make >> it vulnerable. >> We could probably come up with an alternative way to generate and verify >> state variable though. Could be a HMAC for example. >> So you would remove the state cookie? > > It could potentially be a solution - I started a separate thread on > keycloak-dev to discuss this. > >> - Login attempt after "Login user action lifespan" leads to "Invalid >> username >> or password." ( https://issues.jboss.org/browse/KEYCLOAK-1015 ) >> I agree that the error message is not very good, but I disagree with >> removing >> the expiration. Why not increase it to say 30 min? That's probably a more >> sensible timeout for reset password as well. >> I prefer an expiration of 5 min for the password update process, but thats >> a >> bit short for the authentication or password reset process. >> I think the best solution would be different expiration times for the >> different processes, wouldn't it? > > Maybe - we do try to keep configuration options to a minimum as these > introduce complexity as well as potentials for bug/security issues. I totaly understand that. You have currently the following actions: OAUTH_GRANT, CODE_TO_TOKEN, VERIFY_EMAIL, UPDATE_PROFILE, CONFIGURE_TOTP, UPDATE_PASSWORD, RECOVER_PASSWORD, AUTHENTICATE, SOCIAL_CALLBACK And it doesn't make sense to have a different conffiguration for every one... But maybe we can group it into different groups? > > >> Do you have any good ideas for a workaround? >> Best >> Michael >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>

From: "Michael Gerber" <gerbermichi(a)me.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; Sent: Sunday, 1 February, 2015 4:09:35 PM Subject: Re: [keycloak-dev] Looking for a workaround... I would look at the following scenario: A user starts with the login process and then takes a long break (15 mins or more) without locking his computer.

There are critical processes like password changes, which should definitely expires after a view minutes and others like authentication which does not matter if they don’t expire during this break.

critical actions: - OAUTH_GRANT - CODE_TO_TOKEN (already seperate) - VERIFY_EMAIL - RECOVER_PASSWORD - UPDATE_PROFILE - CONFIGURE_TOTP - UPDATE_PASSWORD non-critical actions: - AUTHENTICATE - SOCIAL_CALLBACK > Am 30.01.2015 um 14:25 schrieb Stian Thorgersen <stian(a)redhat.com&gt;: > > What groups would you propose? > > ----- Original Message ----- >> From: "Michael Gerber" <gerbermichi(a)me.com&gt; >> To: "Stian Thorgersen" <stian(a)redhat.com&gt; >> Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; >> Sent: Monday, 26 January, 2015 4:23:49 PM >> Subject: Re: [keycloak-dev] Looking for a workaround... >> >>> ----- Original Message ----- >>>> From: "Michael Gerber" <gerbermichi(a)me.com&gt; >>>> To: "Stian Thorgersen" <stian(a)redhat.com&gt; >>>> Sent: Monday, January 26, 2015 2:10:59 PM >>>> Subject: Re: [keycloak-dev] Looking for a workaround... >>>> ----- Original Message ----- >>>> From: "Michael Gerber" <gerbermichi(a)me.com&gt; >>>> To: keycloak-dev(a)lists.jboss.org >>>> >>>> Sent: Monday, January 26, 2015 1:37:53 PM >>>> Subject: [keycloak-dev] Looking for a workaround... >>>> Hi all, >>>> I receive a lot of bug reports from our test team because of the >>>> following >>>> two issues: >>>> - Reset password leads to 400 Bad Request ( >>>> https://issues.jboss.org/browse/KEYCLOAK-1014 ) >>>> This is a tricky one - we can't ignore the state variable as that would >>>> make >>>> it vulnerable. >>>> We could probably come up with an alternative way to generate and verify >>>> state variable though. Could be a HMAC for example. >>>> So you would remove the state cookie? >>> >>> It could potentially be a solution - I started a separate thread on >>> keycloak-dev to discuss this. >>> >>>> - Login attempt after "Login user action lifespan" leads to "Invalid >>>> username >>>> or password." ( https://issues.jboss.org/browse/KEYCLOAK-1015 ) >>>> I agree that the error message is not very good, but I disagree with >>>> removing >>>> the expiration. Why not increase it to say 30 min? That's probably a >>>> more >>>> sensible timeout for reset password as well. >>>> I prefer an expiration of 5 min for the password update process, but >>>> thats >>>> a >>>> bit short for the authentication or password reset process. >>>> I think the best solution would be different expiration times for the >>>> different processes, wouldn't it? >>> >>> Maybe - we do try to keep configuration options to a minimum as these >>> introduce complexity as well as potentials for bug/security issues. >> >> I totaly understand that. >> You have currently the following actions: >> OAUTH_GRANT, >> CODE_TO_TOKEN, >> VERIFY_EMAIL, >> UPDATE_PROFILE, >> CONFIGURE_TOTP, >> UPDATE_PASSWORD, >> RECOVER_PASSWORD, >> AUTHENTICATE, >> SOCIAL_CALLBACK >> >> And it doesn't make sense to have a different conffiguration for every >> one... >> But maybe we can group it into different groups? >> >>> >>> >>>> Do you have any good ideas for a workaround? >>>> Best >>>> Michael >>>> _______________________________________________ >>>> keycloak-dev mailing list >>>> keycloak-dev(a)lists.jboss.org >>>> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>