Questions about session expiry

jgreub commented 2 years ago

Hey, thank you for maintaining this library.

We are trying to use nginx with lua_resty_oidc and therefore lua_resty_session in our project where security is very important. I wanted to ask a few questions about how this library works with session expiry using the default non-persistent cookie strategy and about a persistent cookie strategy. My ultimate goal is to understand and configure the regular session timeouts to be 15 minutes, and then if possible also set an absolute timeout for all sessions (e.g. after 10 hours of activity the session is invalidated).

Non-Persistent cookie strategy questions...

1a. I believe this is the default settings for lua_resty_session, with the session_cookie_storage = cookie; and session_cookie_persistent = off; which results in a cookie with an expiry of session being created in the browser. Do you agree so far?

1b. Cookies with an expiry of session are controlled by the browser, and usually result in the cookie being "expired" or removed once the browser is closed or after a period of time the browser determines, which could be a very long time (e.g. more than an hour). Do you agree with this as well?

1c. Because of this non-persistent cookie configuration, the other settings from this library such as session_cookie_idletime or session_cookie_lifetime have no affect. Is that correct?

Persistent cookie strategy questions...

2a. If my understanding of the previous section is correct, then I believe the only way to set a 15 minute session timeout would be to use a persistent cookie strategy so that I can then use a setting like session_cookie_lifetime. Is that correct?

2b. However, I'm assuming that if I turn session_cookie_persistent = on; then I need to choose a storage strategy of where the cookies are persisted, such as in memory or in redis. Is this true or am I understanding what persistent means incorrectly?

Other questions...

3a. I have read the docs for both session_cookie_idletime and session_cookie_lifetime but I don't really understand the difference. Could you explain it?

3b. Would you know of a way to set an absolute timeout for a session, such that even if a session is kept active for 10 hours, that at 10 hours the session is considered expired?

3c. Lastly, I've read in this libraries docs that the ssl_session_timeout setting might need to be configured correctly as well, but maybe not if "tickets" are being used. Do you think this property needs to be worried about anymore?

Sorry for the many questions, but thank you very much in advance!

bungle commented 2 years ago

@jgreub,

Hi, thanks for this.

1a: I agree. The session cookies in browsers have no expiry, but we store expiry in cookie value. 1b: I agree 1b: It is not correct. lifetime is used to calculate expiry that is store in cookie value. same is done for idle time (which is internally called usebefore). expiry and usebefore are thus absolute times, whereas lifetime and idle time represent duration.

The expiry is calculated as part of the signature, so you cannot just modify it.

There is caveat though with cookie storage. It means there is no way for you to invalidate valid ones on server side. You can change session secret, but that will invalidate all the existing sessions. With server side storage you can delete individual sessions, and there we also expire sessions in server side too.

2a. I think you missed that we store the expiry in cookie value, did I understand that right? 2b. You understood persistence wrong. Persistent here means that cookies are stored on disk, instead of memory. The difference between session cookies and persistent cookies is that persistent cookies have expiry. On browsers it also means that persistent cookies survive the browser process restarts whereas the session cookies don't. Persistent cookies are in many cases used to implement so called remember me functionality (or adverticing cookies).

3a. currently there is a bug with idletime that it does not work with server side storages, but it works with cookie storage. The difference is that lifetime can be say 1 hour, but idle time can be say 10 mins. The idea was to make it so that only the cookie is modified, and we don't need to update possible database (e.g. redis). But it is currently broken as it breaks signature (see: #123). So you can think this as a soft-expiry, as we just trust the browser on this. To fix it we could take idle time away from signature, but then anybody could freely modify it. Alternatively we need to calculate different checksum for that, but that will break cookie format, thus these are going to be fixed in 4.0.

3b. currently at least not tested or documented. session is expanded on usage (depending on the renew), perhaps if you set renew to 0 or -1 you may get the same effect, which means session is not renewed. I have not tested it though. Session lifetime is also expanded on save.

3c. using ssl_session_id aka binding session to ssl session id makes it really hard to steal the session cookies, but it has turned out to be cumbersome in practice (as you need to tune the mentioned directive, and I think there are other issues with that too - does it work with async js, does session id change sometimes unexpectedly etc.). While the idea in theory is nice, it is not that practical. Also there is no session ids when using session tickets. It would be better to bound session to client certificate or something like that.

If you are interested here is a list of possible enhancements that I plan for 4.0:

add support for absolute lifetime of the session (without relying on renew)
- session is not renewed beyond this
- new authentication flow is required after this
fix the idle time to work with server side session storages
- the idle time is increased on cookie only which breaks signature verification
allow same session cookie to be used with multiple authentication flows
- session data needs to support "buckets" and new configuration option is needed to give name of the bucket
- allow limiting number of buckets with LRU/LFU type of logic
associate sessions with some arbitrary user identifier (given to lib)
- allows implementation of n-number of active sessions per user
- allows deletion/revoking the sessions by the specific user without affecting other users' sessions
implement session secret rotation
- allows rotation of session secret with fallback to old secret (for limited time)
client certificate bound sessions?
use more modern defaults and deprecate/remove some of the old stuff

I hope to activate on this at some point this year.

jgreub commented 2 years ago

Hey, thanks for responding with all this information. This information did ultimately help me accomplish my goal on the project I was working on. I think this also showed that I didn't understand all these topics clearly enough as well.

Thanks again, and since I don't have any more questions, I'll close this issue.

bungle / lua-resty-session