zlacker

>>EthanH+(OP)
I wonder if the recommendation for context-aware auth also includes broader adoption of Impossible Travel style checks?

For context, Impossible Travel is typically defined as an absolute minimum travel time between two points based on the geographical distance between them, with the points themselves being derived from event-associated IPs via geolocation

The idea is that if a pair of events breaches that minimum travel time by some threshold, it's a sign of credential compromise; It's effective for mitigating active session theft, for example, as any out of region access would violate the aforementioned minimum travel time between locations and produce a detectable anomaly

>>fire+TX
Is this practical? I would imagine with how peering can get better/worse in an instant (and continuously change as different routers pick up new routes) you can't use ping to measure this, and geoip databases don't seem like a source you could trust, especially with CGNAT throwing you onto some generic IP with a geoIP that everyone else in a 200 mile radius also gets.

>>judge2+ll1
From my experience it isn't a be-all-end-all so much as another point of data for anomaly detection.

In practice, geoip "regions" like used for this _are_ on the larger scale, yes; However that still lets you ask valuable questions like "why is this user who logs in from Vermont, USA suddenly in Hungary?" and potentially do something proactive like limiting that session's resource access until a new MFA challenge has been passed, or ( more aggressively ) destroy the session or otherwise force a full reauth.

The downside is that this almost always relies on some actively maintained geoip database ( ala maxmind ), which... well it isn't exactly cheap, and it isn't exactly perfect, either ( see: maxmind historically putting IPs in a central location when lacking specific data )

Ultimately it's one part of ( what should be ) a suite of checks for anomalous behavior, not something to blindly implement. The latter can cause a great deal of grief if your tolerances are too tight or your proactive actions aren't in line with the activity/abuse they're intended to mitigate.

A pretty direct example of proactive action would be restricting access to using saved payment methods on a platform until the user has completed a new 2fa challenge.

You could require this challenge every time the user wants to buy something, yes, but as that will probably impact checkout rates, you could get many ( if not most ) of the same fraud prevention benefits by only challenging when the session has moved some threshold distance - It won't stop them from buying something at home or a coffee shop in town, but would stop a session hijacker on an opposing coast or another country from doing so.

>>fire+RM2
> "why is this user who logs in from Vermont, USA suddenly in Hungary?"

Maybe because the new login is from a hacker. Maybe because your geoip database provider is unreliable. Either one is likely. There's no sure way to go from an IP address to a location.