> 1: A short compromised session is still a compromised session. The duration usually does not prevent the attacker from achieving their goal.
Need a citation on that “usually” part. A short session duration most definitely:
* Makes it less likely that when an attacker obtains a session token that is is unexpired.
* Gives the attacker less time to use a valid session token to move laterally into (potentially) unfamiliar infrastructure.
The trade-offs, of course, are:
* Poorer UX, and potentially driving users to attempt to bypass approved tools and/or security controls
* More interactions with the authentication system, which, depending on the auth system and the attackers motivation/capabilities might actually let them harvest more credentials.
But, in any case, I’m not aware of any research that short session tokens don’t thwart attackers use of those tokens, and the idea is, to put it mildy, counterintuitive.
Once the attacker knows they can steal the session ID, and how long it will be valid for. It’s just a matter of running a script to do that all that as fast as possible.
The correct way to evaluate security is to consider many different scenarios, and consider how your mitigations affect the likelihoods of all of them, weighted by their impact.
> The correct way to evaluate security is to consider many different scenarios, and consider how your mitigations affect the likelihoods of all of them, weighted by their impact.
NO! that's merely the FIRST step in evaluating security. The next steps are: What sort of threat am I attempting to prevent? How do my mitigations impact usefulness of the product on the whole? And most critically: Are my users better served by adding this security measure?
That is much more likely to be determined based on what the product/tool is trying to achieve. Which brings us right back to: Security is a tradeoff.
There are situations where I think short sessions make sense (ex: changing billing/contact info). There are also situations where short sessions are huge negatives (ex: how well is slack going to work if you get logged out every 15 minutes?)
My proposal is simple: Actually do the damn evaluation, instead of just blindly siding with "moar security = moar better!"
Short sessions are thinking like physical security. Someone can pick any lock, the question is will it take long enough for a human to interrupt the attack?
It doesn’t matter how long a computer has access to the key. How fast it can cause damage is limited by the speed of light, not human fingers.
If you ever leave the credentials where they are accessible, they can be used even if the session expires in three seconds. And if they’re being seen (in motion) why would the session be expiring in three seconds?
Machines hack differently than humans. Don’t think in human timeframes or orders of magnitude. That will let you make mistakes you can’t afford to make.
We live in a world where real time advertising auctions happen. If you think there’s something about that which can’t apply to organized crime you’re gonna be in for a rude awakening when your systems start to fail en masse.
I’ve had to replace a credit card twice for suspicious activity (once cost me my favorite domain name, which is still parked). There were no major charges in either case. One charge at a business I’ve never been to.
Some people get a card and use it. Some immediately sell it after proving it works. That means a clearing house. A food chain. That will get more automated, not less.
Sure, there are some attacker activities that are highly automated. That’s not what we’re talking about here. We’re talking about compromised temporal session tokens, which are frequently harvested by manual action, and in those scenarios, thinking about human timeframes is very useful.
> * Makes it less likely that when an attacker obtains a session token that is is unexpired.
But gives them more opportunities to acquire such token.
> * Gives the attacker less time to use a valid session token to move laterally into (potentially) unfamiliar infrastructure.
Only if tokens lifespan is counted in milliseconds. Otherwise, the attacker will refresh the session token as soon as they get it, and continue to do so. An active session token can be thought as having arbitrary long lifespan.
> But gives them more opportunities to acquire such token.
Maybe, if the session tokens are being acquired by improper logging. If the tokens are acquired via the user’s cookie store, for instance, the total number of session tokens is going to be the same — the user is going to use the applications they use, and the stored session tokens will reflect that.
> Only if tokens lifespan is counted in milliseconds. Otherwise, the attacker will refresh the session token as soon as they get it, and continue to do so. An active session token can be thought as having arbitrary long lifespan.
If the session timeout is based on inactivity, not total life time.
There are instances where session timeouts/forced reauth are useful and where an attacker could not endlessly refresh the token.
> How likely is it for an attacker to get access to the user's cookie jar at a single instant in time only?
Depends on the dwell time the attacker has until detection and eviction, but generally speaking, in the scenario where session tokens are being harvested from a user’s workstation or something like a jump server, the attacker is going to be able to access stored session tokens from the most recent login prior to their gaining access and any that occur during access. In any case, shorter session tokens are going to result in less access for the attacker. There isn’t a scenario that results in more access, and only absurdly contrived scenarios that result in the same access.
> If the token isn't refreshable without a "real token" the "real token" will probably need to be somewhere the attacker can get it anyway.
That may be true of ticket-granting-ticket schemes, but not for single/multifactor authentication for ticket schemes. Both scenarios exist and need to be accounted for appropriately.
UX for common applications is poor. Would you want to have to enter your email password every hour or two, for instance?
I’d argue for truly critical infrastructure, short-ish session times can be useful, but for most applications they do more harm than good and better alternatives exist. For instance:
* Enforcing step-up authentication for access to sensitive application functions.
* Forcing re-auth based on behavioral analytics (for instance, if the user normally accesses an app 8 - 5 Monday - Friday from the United States, but presents a session token on Saturday afternoon from Russia, maybe force a reauth.)
* For enterprise apps, SSO where you may be forcing an authentication event every shift, but at least it is one, not one per app.
But, of course, there is no one right answer because there is no universally applicable or agreed upon threat model.
I think this debate is too abstract to be useful. Certainly, there are some cargo cult practices where various forms of "key rotation" has gotten out of hand for no real benefit. But there are many valid scenarios which depend on different overall system characteristics. I'll just revisit a few.
1. Actual encryption key rotation. This is one grandparent of modern session limits, built with an assumption that keys might be compromised by cryptanalysis rather than stolen by malware-infected clients etc. Rotation reduces the number of ciphertext examples made available to perform the cryptanalysis, thereby reducing the risk of successful attacks. It also may reduce the scope of compromised data if and You may have a UX requirement for preventing idle sessions to stay open on clients because people are in a shared space with client devices, i.e. HIPAA touches on this for medical systems. only if key exchange is still considered secure, such that holding one key does not let you decode traffic captures to determine earlier/later keys in a transitive attack.
2. Forcing idle logouts with less dependence on client systems. This is another grandparent of modern limits which is sometimes cargo-culted. The underlying risk is people logging in and then abandoning a terminal in a shared space, so you want to reduce the chance that someone else can walk up and start using it. You really want the client system to participate in this, i.e. not just end a session but lock/clear the screen so previous data is not on display for unauthorized observers. But it is often seen as defense in depth to also abort the remote session credentials so that future actions are unauthorized even if the client software has failed to do its part, such as if it has crashed/hanged. This one has the weakness you mention that a malicious client could do endless refresh to prevent the detection of an idle UX by the server.
3. Forcing reauthentication periodically or for high-value actions. This is more paranoid than the prior idle logout concept, and actually demands the user reestablish their authenticity during an active session. This has been used historically as another kind of defense in depth attempt to verify user presence with less trust of the client system. But it is also used as a UX ritual to try to get the user to pay attention as well as build an audit chain for their consent to a specific action. Designers might tie this in with MFA/hardware tokens, to get different kinds of user-presence detection throughout a session.
4. Decentralized "web-scale" architecture and caching. In a traditional system, a session key is little more than an identifier and might be checked on each use, i.e. each web request, to determine actual client identity and privileges with a server-side lookup. But as people developed more distributed services, they have often shifted to embedding more of this info into the session "key" itself, as a larger signed blob. Different service components can decode and operate on this blob without having to do synchronous lookups in a centralized session database. This is where automatic refresh still serves a purpose, because it is during each refresh handshake that the centralized check can occur and potentially reject the refresh request or issue modified privileges. This rotation rate defines a system-wide guarantee for how long it takes certain changes to take effect, e.g. disabling a user account or changing the roles/privileges assigned to a user. I have seen this approach even in systems where the session key is a mere ID and cache invalidation could arguably be handled in the backend without forcing client's session keys to rotate. This seems like cargo culting, but is useful if the system operator wants to retain the option to use signed blobs in the future, and so does not want to allow client programmers to assume that client session keys are stable for indefinite time periods.
Need a citation on that “usually” part. A short session duration most definitely:
* Makes it less likely that when an attacker obtains a session token that is is unexpired.
* Gives the attacker less time to use a valid session token to move laterally into (potentially) unfamiliar infrastructure.
The trade-offs, of course, are:
* Poorer UX, and potentially driving users to attempt to bypass approved tools and/or security controls
* More interactions with the authentication system, which, depending on the auth system and the attackers motivation/capabilities might actually let them harvest more credentials.
But, in any case, I’m not aware of any research that short session tokens don’t thwart attackers use of those tokens, and the idea is, to put it mildy, counterintuitive.