Return to Answer

Yes it is possible.

If tokens are server generated by creating a cryptographically secure random sequence stored against the account, this token could be refreshed and reissued on a certain interval, invalidating the old one.

The token would only be refreshed on active use so it won't invalidate the old one when the client computer is off. This approach ensures that a copied cookie only has a limited time to be reused, limiting exposure of the attack. In the case that the attacker uses the cookie in time, the original session would be expired and the real user would be logged out (depending on how the interval is set). A message could be displayed that the account is being used elsewhere, alerting the user to the attack.

If the attacker has persistent access though and can grab any new identifiers, she has already won. The above only protects against a one time theft of the token. For example if the user left their screen unlocked and the attacker had physical access and only enough time to steal the cookie value, or if the value was stolen via a reflected XSS attack, which is code execution in the browser, and the attack cannot be repeated easily.

An attacker with root access though may or may not be able to grab a normal user's cookie. Chrome encrypts cookies when saved to disk, allowing only the current user to decrypt them as the key is derived from their password. Therefore an attack on tokens on cookies would be more difficult.

Yes it is possible.

If tokens are server generated by creating a cryptographically secure random sequence stored against the account, this token could be refreshed and reissued on a certain interval, invalidating the old one.

The token would only be refreshed on active use so it won't invalidate the old one when the client computer is off. This approach ensures that a copied cookie only has a limited time to be reused, limiting exposure of the attack. In the case that the attacker uses the cookie in time, the original session would be expired and the real user would be logged out (depending on how the interval is set). A message could be displayed that the account is being used elsewhere, alerting the user to the attack.

If the attacker has persistent access though and can grab any new identifiers, she has already won. The above only protects against a one time theft of the token. For example if the user left their screen unlocked and the attacker had physical access and only enough time to steal the cookie value, or if the value was stolen via a reflected XSS attack, which is code execution in the browser, and the attack cannot be repeated easily.

An attacker with root access though may or may not be able to grab a normal user's cookie. Chrome encrypts cookies when saved to disk, allowing only the current user to decrypt them as the key is derived from their password. Therefore an attack on tokens in cookies would be more difficult.

Yes it is possible.

If tokens are server generated by creating a cryptographically secure random sequence stored against the account, this token could be refreshed and reissued on a certain interval, invalidating the old one.

The token would only be refreshed on active use so it won't invalidate the old one when the client computer is off. This approach ensures that a copied cookie only has a limited time to be reused, limiting exposure of the attack. In the case that the attacker uses the cookie in time, the original session would be expired and the real user would be logged out (depending on how the interval is set). A message could be displayed that the account is being used elsewhere, alerting the user to the attack.

If the attacker has persistent access though and can grab any new identifiers, she has already won. The above only protects against a one time theft of the token.

Yes it is possible.

If tokens are server generated by creating a cryptographically secure random sequence stored against the account, this token could be refreshed and reissued on a certain interval, invalidating the old one.

The token would only be refreshed on active use so it won't invalidate the old one when the client computer is off. This approach ensures that a copied cookie only has a limited time to be reused, limiting exposure of the attack. In the case that the attacker uses the cookie in time, the original session would be expired and the real user would be logged out (depending on how the interval is set). A message could be displayed that the account is being used elsewhere, alerting the user to the attack.

If the attacker has persistent access though and can grab any new identifiers, she has already won. The above only protects against a one time theft of the token. For example if the user left their screen unlocked and the attacker had physical access and only enough time to steal the cookie value, or if the value was stolen via a reflected XSS attack, which is code execution in the browser, and the attack cannot be repeated easily.

An attacker with root access though may or may not be able to grab a normal user's cookie. Chrome encrypts cookies when saved to disk, allowing only the current user to decrypt them as the key is derived from their password. Therefore an attack on tokens on cookies would be more difficult.

Yes it is possible.

If tokens are server generated by creating a cryptographically secure random sequence stored against the account, this token could be refreshed and reissued on a certain interval, invalidating the old one.

Yes it is possible.

If tokens are server generated by creating a cryptographically secure random sequence stored against the account, this token could be refreshed and reissued on a certain interval, invalidating the old one.

The token would only be refreshed on active use so it won't invalidate the old one when the client computer is off. This approach ensures that a copied cookie only has a limited time to be reused, limiting exposure of the attack. In the case that the attacker uses the cookie in time, the original session would be expired and the real user would be logged out (depending on how the interval is set). A message could be displayed that the account is being used elsewhere, alerting the user to the attack.

If the attacker has persistent access though and can grab any new identifiers, she has already won. The above only protects against a one time theft of the token.