What Are Geo-Location and Geo-Velocity in Identity Authentication?
Geo-location and geo-velocity are just two of the pre-authentication risk checks included in SecureAuth’s adaptive access control solution. Geo-location and geo-velocity can both offer different levels of protection, and may be employed independently or in tandem; but what exactly are they and how do they work?
Geo-Location in SecureAuth Identity Risk Engine Service
Geo-location is the ability of the identity provider to determine the physical location of the device that’s being used by someone attempting to identify themselves. You no doubt have run into a geo-location check without even realizing it when using common web services like search engines, video streaming sites, and major websites that serve many worldwide customers. When you connect to such a site, your IP address is checked to determine where the endpoint you are connecting from is physically located. This check is performed by a risk/threat service, which we call SecureAuth Identity Risk Engine Service.
Some tools can also determine more accurate location information by triangulating cellular signals or using on-device GPS systems. Together, these tools provide at least a general – and often a very specific – geographical location for the device you are using to make the login attempt.
With this information, the service provider can determine if you should be granted access to a particular set of resources based on where you are in the world. For example, the British Broadcasting Company (BBC) only allows the use of their iPlayer software when you are connecting to that service from within the United Kingdom and a limited set of other locations. If you try to access iPlayer from the United States, your geo-location data shows that you are not within the service area, and re-directs you to another webpage that explains that you cannot get access from your current location. In many cases, geo-location is used to ensure that customized versions of websites are displayed to users in different countries for localization of language and site content.
In Identity and Access Management, companies may wish to limit access to corporate resources to only those physical locations where employees are actually likely to be stationed.
For example: If you work for a company that only does business in the Northeast United States, and has no employees which work from other areas of the country, then only those who attempt to access company resources from locations in the Northeast US will be permitted to log in. Since employees may travel to other areas of the country and world, geo-location may not trigger a lock-out or denial, but rather trigger a requirement to use multi-factor authentication (also known as step up authentication using MFA) or take other steps before access is granted to ensure the employee is indeed who they say they are since they’re attempting to log in from a location they wouldn’t normally be.
Geo-Velocity in SecureAuth Identity Risk Engine Service
Unlike geo-location, geo-velocity is less concerned with where you are currently located, but rather the distance between your current location and where you last logged in.
Since even the fastest modes of transportation can only cover so much distance in a given time; an employee logging in while physically in New York City at 9 am couldn’t then log in from Los Angeles at 11 am Eastern Time – 2 hours later. There’s no method of travel that would let them cover that distance in that little time. It’s much more likely that two different people are attempting to log in, which would indicate either fraud or the sharing of login information – both dangerous to the organization.
Geo-Velocity is most usually defined by a maximum miles-per-hour or kilometers-per-hour so that the two locations in questions are less relevant than how fast a human being would have to travel to sign into one and then the other within a given amount of time.
This allows employees who travel, to safely authenticate from different cities as the result of travel – provided that the geo-velocity reports show they made that travel at a speed that meets the logic of modern modes of travel by air, land, and sea. So, an employee who logs in at 11 am Eastern Time from NYC could validate in Los Angeles at 2 pm Pacific Time – since the travel time for that distance by air (taking time zone changes into account) is logical and correct.
Now, geo-velocity also has to take into account that the airplane might have gotten a good tail-wind, or “made up time” in the air, resulting in only a 5 hour trip instead of 6 hours, so these settings may need to be adjusted as real-world examples are analyzed. Short-term, geo-velocity triggers may result in a step-up to multi-factor authentication method instead of blocking access, as the appropriate speeds are calculated through real-world examples.
Putting it together
Taken together, geo-location and geo-velocity can allow an organization to control access to services, only to those who are supposed to be allowed in. By limiting access to particular physical locations and ensuring people aren’t traveling faster than the fastest airplanes would allow; fraudulent users can be denied access while legitimate users are then able to log in without disruption, and suspect users are required to provide additional proof of identity.
Geo-location and geo-velocity are just two of many risk checks SecureAuth Cloud IAM provides as part of its risk-based adaptive authentication. The goal of these and other checks is to strengthen security AND provide a positive disruption-less login experience for users. If no risk present, no MFA step. If medium risk, require an MFA step. If high risk, deny access.
To learn more about risk-based authentication methods, visit our Adaptive Authentication page or contact us.
Identity 101 Blog Series
Identity 101: A Quick Guide to the Top 12 Acronyms in Identity Management
Identity 101: Creating Secure Password
Identity 101: What is Acceptance Fatigue?
Identity 101: When “Good Enough” Just Isn’t Good Enough
Identity 101: Thinking Beyond the Borders of the “Office”
