17

I'm currently implementing a login session system for a web application. I've read lots of articles recommending very low session and idle timeouts. For example OWASP says:

Both the idle and absolute timeout values are highly dependent on how critical the web application and its data are. Common idle timeouts ranges are 2-5 minutes for high-value applications and 15-30 minutes for low risk applications. Absolute timeouts depend on how long a user usually uses the application. If the application is intended to be used by an office worker for a full day, an appropriate absolute timeout range could be between 4 and 8 hours.

And it makes intuitive sense that "if a session ID is stolen, the faster it expires, the better". However, I don't see these shorts session timeouts when using websites like Google, Twitter or GitHub. There, I practically never have to re-login again: the session stays active indefinitely.

How are they achieving this long session time without compromising on security? I've researched already, and I found a few potential reasons, but none of those really convince me:

I've seen articles like this one arguing that the big players can do that because they have additional security features like remote logout, reauthentication prompts for critical actions, login history and login notifications. And that's nice and all, but I don't really see how that would allow for a super long session duration. Most normal users probably never use remote logout, login history or login notifications. And the reauthentication prompts only appear for things like "changing password" and "deleting repository", but there are tons more things that you really don't want an attacker be able to do and which are not secured by these prompts. So this can't be the full reason!

Big websites also have additional protections like binding a session ID to a browser-fingerprint and an IP range. Is that the reason why their long-lived sessions are safe?

Or is the advice about super short sessions found everywhere on the internet outdated? Are stolen session IDs actually still a risk worth considering, assuming you follow best practices (truly random session IDs, >=128 bits entropy, Secure; HttpOnly; SameSite=Lax)? If an attacker can extract cookie values from your local browser, you surely have bigger problems than a compromised session.

Or finally, do the big players just prioritized user experience over security?

schroeder
  • 125,553
  • 55
  • 289
  • 326
Lukas Kalbertodt
  • 333
  • 1
  • 7
  • 2
    My assumption was always that the session does expire if you don't visit the site for a while (a few days/weeks). In my opinion, the security benefits of short-lived sessions are also pretty small relative to the amount of inconvenience they cause when deployed on a frequently-used site. Would love to see a detailed answer to this though. – Ajedi32 Oct 25 '21 at 14:17
  • 2
    https://auth0.com/blog/balance-user-experience-and-security-to-retain-customers/ implies it is partly about UX. No serious bank, no matter how big, let users keep logged in for hours after idle. I suspect extended sessions is more about whether the upper management consider the cost of implementing binding session worth the user retention – Martheen Oct 26 '21 at 02:13
  • 3
    `do the big players just prioritized user experience over security` One might invoke [AviD's rule of usability](/a/6116/129883). If the users are using the application heavily, but you keep making them reauthenticate, they will start using shorter/simpler passwords so they can waste less time on the login page and get back to what they wanted to do. – Fire Quacker Oct 29 '21 at 20:02
  • My vote goes to bindings like browser fingerprinting. If the same browser is used than the old session is still valid, while using another system authentication is required. Google also allows multiple devices to be logged in simultaneously, so there are multiple active sessions. Additionally I guess that actively used sessions regularly change session IDs so that a session ID sniffed a few days ago is not valid today regardless of any other measure. – fleitner Feb 02 '23 at 13:18

3 Answers3

3

No, the bigger comapny do not prioritize user experience over security. Rather, they strive to provide a good balance between user experience and security. While long session lengths improve user experience by avoiding the need to constantly re-login, it is also important to ensure that user data is secure. They achieve this by implementing multiple layers of security mechanisms, such as session binding, reauthentication prompts, login history and notifications, server-side session management, and timeout policies, among others. This way, they can maintain long session lengths while also ensuring that user data is secure.

Big websites can maintain long session lengths without compromising on security by using multiple layers of security mechanisms. They have a combination of the following:

The session ID is bound to a user's browser ( known as Session binding ) fingerprint and IP range. This makes it difficult for an attacker to use a stolen session ID from another device or location.

Sensitive actions like password changes, and big websites prompt users to re-enter their password to ensure the user is still present.

They maintain a record of the user's login activity and notify the user of any suspicious activity. This helps in detecting and preventing unauthorized access.

The session state is stored server-side, making it more secure than storing it on the client-side.

Rudra Sarkar
  • 319
  • 1
  • 9
  • 1
    *The session ID is bound to a user's browser ( known as Session binding ) fingerprint * as evidenced by often getting logged out of multiple sites after a browser update. Not every site, but perhaps those that fingerprint in similar ways – Chris H Feb 03 '23 at 21:18
  • 1
    Yes, that's correct. Session IDs are linked to a user's browser fingerprint, The fingerprint acts as an identifier for the user's device and browsing configuration. If the browser is updated, the fingerprint can change, causing the user to be logged out from sites that use session IDs for authentication. – Rudra Sarkar Feb 04 '23 at 18:48
  • Citation needed for "Session Binding uses browser fingerprint". I can find ***no*** reference to this. – schroeder Feb 12 '23 at 15:26
  • @schroeder in some cases, browser fingerprinting may be used as an additional security measure to verify the identity of the user's device. This is not the primary method of session binding. – Rudra Sarkar Feb 13 '23 at 12:30
  • "The session ID is bound to a user's browser ( known as Session binding ) fingerprint and IP range." -- so, you are now saying that this is false? "Yes, that's correct. Session IDs are linked to a user's browser fingerprint, " -- so you are retracting this statement? It really begins to feel like you are inventing facts on the spot that just "sound good". – schroeder Feb 13 '23 at 22:30
2

I think the main thing on big websites is that they have more security features than the session length. Google gives some words at cloud.google (at point 10). For me the key point is:

Google puts a lot of effort into ensuring users are who they say they are and will double-check based on certain events or behaviors.

They do not go into details here (and i think they do not elsewhere), this is some sort of "security by obscurity" because you don't know how they check your behaviour to determine that you are who you are. But they (and others) have a lot of data about you, so they can decide very precisely. One very basic thing is of course, if you use the same session from another ip address, it is very likely to be stolen. On the link above there are some more best practices from google for user authentication that gave you a view of Google to the whole stuff amd that they are very interested in not afraid user (to type their passwords to often).

D-E-N
  • 180
  • 5
  • 1
    I don't think the IP (or even region) plays a major role in general. I regularly use VPNs to circumvent region locks (e.g. Netflix) and Google has no quarrel with this, my sessions just continue. Even Netflix has no issue with blocking access to videos because I am in the EU and, after a refresh a few seconds later, allow me access as I'm in Australia. – fleitner Feb 02 '23 at 13:13
1

It all comes down to your risk tolerance in regard to session length. Google, Twitter, and Github have apparently made a risk-based decision to implement a combination of advanced security controls, which require a serious investment in appropriate infrastructure, for mitigating the risk of session hijacking (most of which you mentioned in your question).

The risk of session hijacking may be deemed acceptable to gain improved application usability. A better user experience that doesn't automatically log out the user after a short time has apparently been assessed by these corporations to be a more valuable business asset than the risk of session hijacking threats with these advanced security controls in place.

That's not to say that ignoring session timeout directives is safe, especially if your web application is not built with these risk mitigation features.

The question of how long a session to allow will again depend on your risk tolerance level. It's important not to assume that other's risk-based priorities would apply to your application.

Diane Stevens
  • 29
  • 3