I read the federal government’s Zero-Trust Memo so you don’t have to

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

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.

Most likely GeoIP information is used as one of many inputs to a neural net that decides whether you can log on or not (see tons of "Google locked me out" examples).

Any kind of tunnel or VPN would also mess with the minimum travel time. This seems like a good way to cause more problems for regular people just trying to log in from slightly unusual network configurations than for any hypothetical man-in-the-middle.

Wouldn't work for VPN and authorized delegation. Very bad idea.

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.

I'm constantly traveling between Seattle (home) and San Jose (vpn1) or Boardman, OR (us-west-2) according to "logged in from X", so doesn't really work unless you offsetting rules/attributes.

Geolocation is often unreliable. There's no sure way to go from IP address to accurate location, its all based on guesses on how things got routed previously. My previous home routinely showed up as a different country in many different geoip databases, so for me something like that would have always instant-banned me if I switched from cellular (which a lot of databases places me about 100mi away from my home) to home WiFi that would show a jump of 1,000mi.

Even giant orgs like Google who should be good at this will fail at this. I've had services with their Cloud Armor set to disallow connectivity from non-US connections, and yet connections in the US get flagged as non-US even when a traceroute shows no hops going overseas.

> "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.

Right; I covered that explicitly further down in the post.

I wish I had made it more clear in my original post that Impossible Traveler checks are not a magic bullet, as most are assuming that this would be used all on its own for whether to bar access.