13

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
  • 123,438
  • 55
  • 284
  • 319
Lukas Kalbertodt
  • 293
  • 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
  • 1
    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
  • 1
    `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

1 Answers1

1

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
  • 170
  • 5