I recently had an idea about this:
Why is the geo-location not used as authentication to ensure ownership of an account/login in addition to a password? This would work over GPS which is quite precise nowadays, up to 5 metres or so. I see that certain problems come with this, especially that not every device has GPS. In my humble opinion, I think it's easier than dragging a hardware token around.
Does something like this already exist?
What problems do you see in this?
Generally, and putting MFA aside, there is a reason why a mobile app requires permission to access location data: it's a massive privacy violation.
If every service suddenly could gather this information at will (for whatever reason, including authentication) then each service can physically track the device in space.
Breaches in geo-location databases in things like fitness trackers exposed a secret army base. The fitness tracker was tracking multiple military personnel as they ran laps around the base (which was not on any map).
Social media posts are advising people in Ukraine to turn off their GPS so gatherings of people cannot be mapped in real-time.
So, blindly adding this data collection to a service has very real and serious implications and you need to permit the user to choose to turn this on and off at will. And that weakens it as an authentication factor.
Again, more generally, Microsoft AD has had the ability for years to block or limit AD logins based on geo-location. And for some contexts, that can make sense. Especially if all logins were supposed to only occur on the machines in known office locations.
But in an increasingly mobile world, it makes less and less sense to be able to limit logins to within 5 metres, as you suggest.
When we specify an additional factor for authentication, we want to rely on being able to verify this information on the server side, because clients can and do lie to us. A security factor where we trust the client is not very helpful.
With TOTP or FIDO2/WebAuthn, this verification is via a cryptographic means. However, with geolocation, we rely on the client to tell us its location using an API on the client side, either involving a GPS receiver or data about local Wi-Fi networks. The result is then sent to the server. A client can full well spoof this information if they choose (and there are even websites that tell you how to do so), and so it is not useful as an additional factor.
Additionally, geolocation is not usually very interesting to tell us if someone is authorized. Most days, I work from home, and it's unlikely that an attacker can physically be present in my home. However, they could full well sit outside my apartment building or spoof my location. I do, however, sometimes work from somewhere else, like a co-working space or the library, and doing so shouldn't prevent me from gaining access. Nor should the situation where my ISP or my electric or water provider turns off an essential utility and I have to go work from a coffee shop. Similarly, if I'm visiting a friend out-of-town, even in a different country, that should also be okay.
As schroeder mentioned, location is also highly sensitive and identifying, and using it as an additional factor would be a serious invasion of privacy. Because there are solutions which are ultimately substantially more effective and substantially less invasive, it seems prudent for us to use them instead.
