3 ms·

> 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

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

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.