3 ms·

Hardware keys do not prevent session hijacking. If your IT department is empty-headed enough to share active session cookies, you are toast no matter what MFA y

Hardware keys do not prevent session hijacking. If your IT department is empty-headed enough to share active session cookies, you are toast no matter what MFA you use.

rbut 3y ago
Tying sessions to the user's IP would help prevent this, but it comes with it's own issues. Even better don't put admin tools on the open internet, put them behind a VPN like wireguard. Then if the session cookies are stolen, they can't even access them anyway.
- g_p 3y ago
  I wonder if we will see "zero trust" going full circle, and back to isolating privileged systems from the internet, on the basis of endpoint compromises stealing user session cookies. Just making the authentication and service endpoints inaccessible online significantly reduces the attack complexity.
  - wepple 3y ago
    Except “inaccessible” != “vpn” There are a bunch of things folks forget when talking down zero trust; EG if it is done properly then the endpoint the user is using has to AuthN too, and be in good health. That solves cookie/token theft, forcing the attacker to fully route through the endpoint.
  - bayindirh 3y ago
    Actually, not putting administrative or sensitive servers behind a public key + certificate authenticated VPN baffles me. It's very simple and very effective. Also has no usability problems whatsoever.
DanielHB 3y ago
to be fair session cookies at least expire at some point. You can't completely hijack the users account with them.
- usrusr 3y ago
  If you have a hardware second factor that does not require user interaction (or that has a low-security tier that does not require user interaction), couldn't that be used to transparently re-validate existing sessions with zero inconvenience cost? Keep challenging that factor with the existing session and a nonce. Am I missing something? And even if you don't have that, when authentication is your core business you might want to harden your sessions against transmission contents getting in the wrong hands by setting up an additional factor in the browser's local storage that gets challenged without putting the key on the wire. Sure, that local storage is no secrets vault, but you don't write some existing secret there, you set up an additional key that would protect e.g. from a .HAR playback. That's the nature of multi-factor tiered defense, protection from just one angle is protection nonetheless, perfect must not be the enemy of good.
  - insanitybit 3y ago
    That's actually what GSuite's Context Aware Access does if the downstream service supports it (GSuite does, ofc). It will rechallenge your client on every request (client can cache). Exfil of the token won't work if that challenge includes hardware verification.
duckmysick 3y ago
What are the ways to prevent session hijacking? I know short expiration policies help mitigate the damage, but I wonder what else is typically done.

Hardware keys do not prevent session hijacking. If your IT department is empty-headed enough to share active session cookies, you are toast no matter what MFA you use.

rbut 3y ago

Tying sessions to the user's IP would help prevent this, but it comes with it's own issues. Even better don't put admin tools on the open internet, put them behind a VPN like wireguard. Then if the session cookies are stolen, they can't even access them anyway.

g_p 3y ago
I wonder if we will see "zero trust" going full circle, and back to isolating privileged systems from the internet, on the basis of endpoint compromises stealing user session cookies. Just making the authentication and service endpoints inaccessible online significantly reduces the attack complexity.
- wepple 3y ago
  Except “inaccessible” != “vpn” There are a bunch of things folks forget when talking down zero trust; EG if it is done properly then the endpoint the user is using has to AuthN too, and be in good health. That solves cookie/token theft, forcing the attacker to fully route through the endpoint.
- bayindirh 3y ago
  Actually, not putting administrative or sensitive servers behind a public key + certificate authenticated VPN baffles me. It's very simple and very effective. Also has no usability problems whatsoever.

DanielHB 3y ago

to be fair session cookies at least expire at some point. You can't completely hijack the users account with them.

usrusr 3y ago
If you have a hardware second factor that does not require user interaction (or that has a low-security tier that does not require user interaction), couldn't that be used to transparently re-validate existing sessions with zero inconvenience cost? Keep challenging that factor with the existing session and a nonce. Am I missing something? And even if you don't have that, when authentication is your core business you might want to harden your sessions against transmission contents getting in the wrong hands by setting up an additional factor in the browser's local storage that gets challenged without putting the key on the wire. Sure, that local storage is no secrets vault, but you don't write some existing secret there, you set up an additional key that would protect e.g. from a .HAR playback. That's the nature of multi-factor tiered defense, protection from just one angle is protection nonetheless, perfect must not be the enemy of good.
- insanitybit 3y ago
  That's actually what GSuite's Context Aware Access does if the downstream service supports it (GSuite does, ofc). It will rechallenge your client on every request (client can cache). Exfil of the token won't work if that challenge includes hardware verification.

duckmysick 3y ago

What are the ways to prevent session hijacking? I know short expiration policies help mitigate the damage, but I wonder what else is typically done.