Re: [keycloak-dev] Looking for a workaround...

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