4:09 p.m.
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>:
What groups would you propose?
----- Original Message -----
> From: "Michael Gerber" <gerbermichi(a)me.com>
> To: "Stian Thorgersen" <stian(a)redhat.com>
> Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org>
> 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>
>>> To: "Stian Thorgersen" <stian(a)redhat.com>
>>> 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>
>>> 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
>>>