4 ms·

> 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

> 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.

water9 3y ago
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.
- klodolph 3y ago
  That’s one possible scenario. 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.
  - horsawlarway 3y ago
    > 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!"
    - marcus0x62 3y ago
      > My proposal is simple: Actually do the damn evaluation, instead of just blindly siding with "moar security = moar better!" Agree 100% on this.
- hinkley 3y ago
  I will posit this proposition: 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.
  - marcus0x62 3y ago
    > Machines hack differently than humans. An awful lot of hacking is done manually, by humans. For many scenarios, considering human timeframes is completely reasonable.
    - hinkley 3y ago
      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.
      - marcus0x62 3y ago
        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.
TeMPOraL 3y ago
> * 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.
- marcus0x62 3y ago
  > 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.
  - iudqnolq 3y ago
    How likely is it for an attacker to get access to the user's cookie jar at a single instant in time only? > There are instances where session timeouts/forced reauth are useful and where an attacker could not endlessly refresh the token. 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.
    - marcus0x62 3y ago
      > 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.

water9 3y ago

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.

klodolph 3y ago
That’s one possible scenario. 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.
- horsawlarway 3y ago
  > 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!"
  - marcus0x62 3y ago
    > My proposal is simple: Actually do the damn evaluation, instead of just blindly siding with "moar security = moar better!" Agree 100% on this.
hinkley 3y ago
I will posit this proposition: 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.
- marcus0x62 3y ago
  > Machines hack differently than humans. An awful lot of hacking is done manually, by humans. For many scenarios, considering human timeframes is completely reasonable.
  - hinkley 3y ago
    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.
    - marcus0x62 3y ago
      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.

TeMPOraL 3y ago

> * 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.

marcus0x62 3y ago
> 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.
- iudqnolq 3y ago
  How likely is it for an attacker to get access to the user's cookie jar at a single instant in time only? > There are instances where session timeouts/forced reauth are useful and where an attacker could not endlessly refresh the token. 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.
  - marcus0x62 3y ago
    > 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.