This is a concern of mine on systems I design/maintain.
How do I mitigate a stolen cookie from successfully authenticating someone else?
Do I store user browser-agent/IP and check that on every request?
How do I mitigate a stolen cookie from successfully authenticating someone else?
Do I store user browser-agent/IP and check that on every request?
I can often switch thru many IP addresses in an hour (especially travelling) - various WiFi points, 4G, etc. Services will appear incredibly broken these days if they require a new login per IP address.
Obviously you could force all traffic to be routed thru a VPN and list it there, but it seems people are moving away from that approach.
To me, the better question is how are these cookies get stolen in the first place?
Otherwise you probably need short-lived cookies that get renewed by the client in the background, with a hard expiry of some reasonable "work day" length such as 8, 12, 16 hrs. Then even if it's stolen, there's a fairly short window of time that it's useful to anyone.
If you want to avoid this, you have to use something in your authentication scheme that can't leave the device/user, so we're talking certificate or other public key crypto based schemes.
TLS mutual authentication is one common tactic for this, although the scenario itself is uncommon.
Instead what I'd think I'd like is just the risk assessment to be be performed by a third-party when I'm handling authentication (i.e. a third-party that has a broader view of what's happening across multiple services over time). I just send the pieces of information that I'm willing to share as an API call and they make the best risk assessment they can.
Then I can take that risk assessment result and make a final decision if authentication succeeds or not.
https://sift.com/ Is one you call out to that gives you a risk score.
https://datadome.co/ can sit within your cdn layer that does risk assessment.
Besides, if you're large enough it makes business sense to do it yourself anyway.