Session cookies and expiration

[jimfenton]

External comment from Zach Bjornson zbjornson@primitybio.com:

In SP 800-63B, Section 7.2 states:

The nature of a session depends on the application, including:

    1. A web browser session with a “session” cookie, or

    2. An instance of a mobile application that retains a session secret.

Session secrets SHALL be non-persistent. That is, they SHALL NOT be retained across a restart of the associated application or a reboot of the host device.

As worded, it's unclear if "session secrets" in the second paragraph refers to both #1 and #2, or only to #2. If this does apply to web browser "session" cookies (#1), the implication is that the "max-age" and "expires" cookie properties should not be used so that browsers do not retain the cookie after the browser is closed. However, section 7.1.1 item 4 states:

[Cookies] SHOULD be tagged to expire at, or soon after, the session's validity period. This requirement is intended to limit the accumulation of cookies...

Thus, these sections appear to conflict, although 7.1.1 is only recommended and not required. One possible interpretation of 7.1.1(4) is that by not setting a "max-age" or "expires" cookie property, the cookie will effectively expire when the session ends. Alternatively, these items do not conflict if 7.2 only refers to mobile application session secrets, but that seems unlikely. Could you please clarify the intent here?

Additionally, I'd like to point out that many browsers have a "session restore" feature enabled by default that restores cookies as if the browser was never closed. See:

Chrome https://bugs.chromium.org/p/chromium/issues/detail?id=128513

Firefox https://bugzilla.mozilla.org/show_bug.cgi?id=443354

Considering this, the only way I've determined to fully conform to the guidance would be to (1) not set "max-age" or "expires", (2) use a "heartbeat" for each client to check if they are still connected and active, and (3) destroy sessions if the heartbeat is interrupted. This is a moderately large undertaking compared to the rest of the guidance.

Finally, thank you for releasing this publication. I appreciate that it is logical, progressive and clear.

Thanks and best, Zach Bjornson, Ph.D.

[jimfenton]

The comment is correct; session cookies do not have an expiration, so the statement about tagging with certain expiration values is moot. But as it says, the reason for it is housekeeping; the actual enforcement of the cookie expiration is done by the RP and does not depend on the cookie expiring out of the subscriber's browser.

[jricher]

So here's the thing about this: today's browsers don't ever "close" a session like they used to. What does it mean to "close" a browser on your mobile phone, for example? Switch to another application? Explicitly close the tab? Have the app harvested by the memory manager? Reboot? In a lot of these cases, the session cookies stick around. Desktop browsers like Chrome often keep session cookies around anyway, even if you completely kill the browser and reopen it.

[jimfenton]

That's the point of the comment: the notion of a "session" depends on the situation. The "SHALL NOT be retained" thing can't be enforced (e.g. in Chrome, as you point out) and doesn't matter anyway since it is the RP that maintains the sense of a session. We should keep the requirement as a SHOULD because it helps keep session cookies from accumulating.

[zbjornson]

I didn't realize my email comment ended up here. Five years later...

The "SHALL NOT be retained" thing can't be enforced (e.g. in Chrome, as you point out)

This was meant to be the core of my comment (starting from "Additionally..."). There's no way to reliably implement this.

...and doesn't matter anyway since it is the RP that maintains the sense of a session.

The server only knows how long it's been since the last user interaction with the server. Using that, it's possible to implement 4.{2,3}.3's inactivity timeouts.

However, a website server can't reliably know if all of the site's tabs were closed (and reopened):

• Session cookies get restored
• sessionStorage gets restored
• window.addEventListener("beforeunload", () => navigator.sendBeacon("/signout")) is unreliable because that event isn't emitted in all cases, and would require cross-tab coordination to only sign out after all tabs are closed.
• A heartbeat mechanism has the potential to "flap" if the network connection isn't great.
• Anything using JavaScript won't work if the user has disabled JavaScript.

Can 7.2 be revised so that it's possible to meet the guideline that "[session secrets] SHALL NOT be retained across a restart of the associated application"? Or is there a way to do this that I'm not thinking of?

[tracker1]

If the actor isn't using a browser... there's also no way for the server to know you're actually using a browser anyway and the rabbit hole can just circle downward. So I guess, you can just never actually use a browser, you'll have to use a custom client with encryption baked into said client then. I noes, someone could capture the encryption client verification logic and spoof that... we all die then.

In the end, if you're using a standard interface, meant to operate in a standard way, for a standard browser, you're making reasonable accommodations. Just my $.02.

--- edit:

Understanding that Chrome doesn't always close... you could use communications between tabs and use sessionStorage which will be destroyed with a given tab... I've used exclusively session storage for more secure apps, and when opening a new tab, would pass that along or have it re-acquire an auth token.... you can also have a fixed experiation window an JS based auto-refresh, meaning closing for longer than that window has the effect of the session being dead. You can also der server-side cache/check too.