Provide sensible defaults for xpack.security.session.{lifespan|idleTimeout}

[azasypkin]

Currently we don't set any values for xpack.security.session.{lifespan|idleTimeout} by default and hence users sessions stay active until the browser is closed.

It's widely accepted that infinite sessions (browsers may stay open for months) are suboptiomal and with introducing of server-side sessions in #68117 such sessions may introduce technical challenges since there won't be any criterion we can rely on to automatically invalidate such sessions as a part of the cleanup routine. Such sessions will be removed from the Elasticsearch index only if user explicitly logs out unless we provide an admin UI to do that through Kibana (although possible, but unlikely in the nearest future).

Elasticsearch API keys, by default, never expire. But these serve a different purpose and cannot be used as a reference here.

Default expiration time for Elasticsearch tokens is 20 minutes and maximum lifetime is 1 hour.

We don't need to be that aggressive, but we must suggest reasonable non-infinite defaults. Ideally for both idleTimeout and lifespan, but I don't have a strong opinion on that or the values we should pick. The more or less relaxed version I can think of is:

xpack.security.session.idleTimeout: 1h or 2h
xpack.security.session.lifespan: 30d or disabled by default like it's now

It'd be a breaking change, so the earliest version we can do that in is 8.0.0.

What do you think @elastic/kibana-security?

Blocked by: #53478, #22374

[azasypkin]

Decision

We agreed on the following:

Kibana version: 8.0.0+

Defaults:

• xpack.security.session.idleTimeout: 1h
• xpack.security.session.lifespan: 30d

Prerequisites:

• We should remove custom defaults that are set in ESS currently
• Fix Properly handle very long URL fragments captured during SAML handshake #53478
• Fix Large session timeout number expires session almost instantaneously #22374

[legrego]

Thanks for raising this!

I agree that we should be providing sensible defaults to be secure out-of-the-box. My initial reaction is to set xpack.security.session.idleTimeout to perhaps 1h, and to leave xpack.security.session.lifespan unset for the time being. I don't have a particularly strong opinion on the values though.

You brought this up in the context of #68117. While sensible defaults here will help with session cleanup, it won't eliminate the technical challenge you're facing there, right? We will still allow users to unset either of these values, or to set them arbitrarily high to the point that they're effectively disabled.

[azasypkin]

While sensible defaults here will help with session cleanup, it won't eliminate the technical challenge you're facing there, right? We will still allow users to unset either of these values, or to set them arbitrarily high to the point that they're effectively disabled.

Correct, it will just reduce the impact this new change will have by default + make the decision/consent to keep session info indefinitely more explicit.

[jportner]

I agree we should set some sensible defaults. As to what the values should be:

NIST SP 800-63 guidelines suggest a 30-day re-authentication requirement for "AAL1" (the lowest assurance level). For "AAL2", they suggest a 12-hour re-authentication requirement and a 30-minute inactivity timeout. (Reference)

Not saying that we need to adhere to NIST, but it's always helpful to keep industry standards in mind. The guidelines seem to suggest that the inactivity timeout (idleTimeout) is supplemental to the re-authentication requirement (lifespan). if we're going to pick one, I'd prefer to set the lifespan. If we only set the idleTimeout, it could still result in an infinitely-lived session if it's stolen by an attacker.

It's also worth noting that, currently, Kibana supports a maximum session lifespan value of approximately 24 days. We could increase that on the client side by using an abstraction layer around the setTimeout API. Reference: #64264 (comment)

[azasypkin]

NIST SP 800-63 guidelines suggest a 30-day re-authentication requirement for "AAL1" (the lowest assurance level). For "AAL2", they suggest a 12-hour re-authentication requirement and a 30-minute inactivity timeout. (Reference)

Thanks for the reference link, it's a good one. Tried to find something similar in ENISA specs, but without luck.

Not saying that we need to adhere to NIST, but it's always helpful to keep industry standards in mind.

I agree, it's always better to have a well-known source of recommendations we can reference to.

If we only set the idleTimeout, it could still result in an infinitely-lived session if it's stolen by an attacker.

That's a very good point!

It's also worth noting that, currently, Kibana supports a maximum session lifespan value of approximately 24 days. We could increase that on the client side by using an abstraction layer around the setTimeout API. Reference: #64264 (comment)

Yeah, it shouldn't be too difficult to fix that.

---

I'm hesitant to stick to AAL2 by default, but having 30-day re-authentication requirement from AAL1 plus 1h inactivity timeout by default sounds like a good middle ground to me.

Any objections if we go with these values?

[legrego]

I'm hesitant to stick to AAL2 by default, but having 30-day re-authentication requirement from AAL1 plus 1h inactivity timeout by default sounds like a good middle ground to me.

This seems reasonable to me. If possible, we should strive to resolve #53478 by 8.0 as well, so that we don't risk losing the user's current state when they go to re-authenticate (I know you mentioned trying to resolve it as part of #68117).

[azasypkin]

This seems reasonable to me.

Good 👍

If possible, we should strive to resolve #53478 by 8.0 as well, so that we don't risk losing the user's current state when they go to re-authenticate (I know you mentioned trying to resolve it as part of #68117).

Definitely! I fixed it for SAML and OIDC locally already (in the scope of #68117), but will likely extract this to a dedicated PR or a separate commit at least.

[jportner]

I'm hesitant to stick to AAL2 by default, but having 30-day re-authentication requirement from AAL1 plus 1h inactivity timeout by default sounds like a good middle ground to me.

I agree!

[azasypkin]

I agree!

Great 👍 I'll wait till next Wednesday (17/06/2020) to make sure everyone else can express their opinion or objections, and then [Discuss] ➡️ [Actionable Issue].

[azasypkin]

Thanks a lot everyone for the feedback! Recorded final decision in #68885 (comment).