Short session expiration does not help security

Happens all the time, where access is through a low privilege user, or the nature of the infiltration isn't just a user but through some specific tool that only itself has access to specific things. Maybe the hack gets you into Splunk and that's it, and only for a few hours because the session you hijacked expires...

Nobody exposes access tokens on purpose, there is no "its job includes creating access tokens". No system's job results in this happening as part of normal operation.

Also 100% wrong re: "it definitely has access to the database that stores user accounts". That statement makes me think you have no clue what you're talking about; you don't need access to users at all to validate a session token. In a JWT, the token is signed and you validate the signature with a cert, and that cert is public knowledge.

I've written auth services that have zero access to password data, which validate session tokens.

The point I was trying to make about that is that most businesses don't have the financial resources to absorb the cost of "security" as it's being practiced now. Yet it's continually being foisted upon them as a necessity.

> Facebook, Google, Amazon and GitHub have sessions that never expire. They think it’s an acceptable risk. I think they are right.

Three of these companies have a strong vested interest in keeping you logged in all the time and to minimize the friction of interacting with their services.

GitHub, if you use 2FA or corporate SSO, does expire sessions. Perhaps they make the tradeoff of risk vs convenience for username/password users, as is their right.

The shorter tokes are useless by themselves; but if combined with proactive security, they can make a real difference. Some concrete examples, based on the places I worked in, which provide support for at least not having infinite expiration:

- Attacker steals Google token from regular employee.. What can they do? No, they can't "make themselves admin, or wire all your bitcoin to their account" because such things are not available for regular employees. Nor can they use email to take over account because all stuff that matters uses corporate SSO without automated password resets. So all they have access to corporate google drive, which has few terabytes of not so-valuable-stuff + important documents somewhere.

With long-living token, the attacker has plenty of time to browse around and download valuable stuff, perhaps even do it slowly so it can fly under radar. But with the shorter token, this does not work: downloading everything will take too much time / trip the alarms, and manual browsing is not fast enough. (I can imagine some sort of sophisticated AI system which auto-downloads interesting docs, but I am sure most attackers have nothing like this)

- Attacker steals AWS credentials -- again, they either have to be fast and get detected (there are alarms on unusual high download rate) or go slow and worry about token expiration. Even if they manage to steal important data, at least the expiration will force them to use faster methods more likely to trip the alarm.

Even with the full machine compromise, the short-lived tokens are useful. A npm package which steals all tokens once, at the install time, will likely go undetected. A npm package which installs a persistent backdoor will be much easier to detect.. So having a long-lived token makes attackers' lives much easier.

> Vendors In Depth

Vendors will always love the phrase 'defense-in-depth' more than they care about assessing whether additional layers of tooling and controls actually provide more defense, because a vague appeal to defense-in-depth is a great way to justify purchasing more security software.

It would be naive to think this doesn't affect the volume of research produced promoting and emphasizing the importance of defense-in-depth either, or how frequently papers on basically any kind of attack end with something that means 'this is why a defense-in-depth approach is needed in XYZ area' even when defense-in-depth is at best incidental to the substance of the paper.

You can trivially tack that on to the end of pretty much any paper about any exploit, which raises the question of how meaningful an observation it really is.