3 ms·
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 brows
by hu3 5y ago
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?
- throwawayboise 5y agoIf it's an internal corporate system where all the users sit at assigned machines and have fixed IP addresses, yes you can do stuff like IP address checking. 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.
- josho 5y agoIn my opinion you don’t. Rely on the authentication provider to handle that responsibility. Services like duo/Okta perform this risk assessment and may opt to request a mfa request.
- hu3 5y agoThat's not always an option.
- hu3 5y agoYou can downvote all you want. Some projects are sensitive enough to not allow third party authentication (military systems anyone). Besides, if you're large enough it makes business sense to do it yourself anyway.
- bradleydwyer 5y agoI've never wanted to completely hand over authentication to a third-party. 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.
- jsmeaton 5y agoThere are risk services out there. https://sift.com/ https://sift.com/ Is one you call out to that gives you a risk score. https://datadome.co/ https://datadome.co/ can sit within your cdn layer that does risk assessment.
- martinald 5y agoI think we are living in a post "IP address" world to be to totally honest. 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?
- foxpurple 5y agoIP based auth is super annoying for legitimate users since it logs them out frequently.
- munchbunny 5y agoAs long as your authentication scheme is based on a bearer token, you can't really prevent it, but binding to IP and setting short expiry can help motivate it. 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.
- staticassertion 5y agoIf the client device has a TPM or some sort of hardware that can manage the secret you can leverage that. Otherwise, protecting against "attacker has a valid session" is not very easy. Even in the TPM case attackers with code execution on the device can likely bypass it.