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?