0 s
Between a New York and a Berlin attempt in our example
Velocity check · Geo-velocity
Impossible Travel Detection
Impossible travel detection flags a login or transaction that would require the user to cross the map faster than any person can. A sign-in from New York followed by one from Berlin 90 seconds later cannot both be genuine. Spriv runs this velocity check on the phone's real location, on a second channel, automatically and in real time.
Impossible Travel Detection · Distance divided by time
0
Separate channels: the login and the phone
0 ms
Typical second-factor time for real users
0
Phone locations shared with your app
The basics
What is impossible travel?
Impossible travel is a pair of events on one account, a login, a payment or a password change, whose locations are too far apart for the time between them. If the user would have needed to fly faster than an airliner, at least one of the two events was not made by them.
Shared or stolen credentials
The classic cause: the real user signs in at home while an attacker with a phished or leaked password signs in from another continent.
Card and payment fraud
A card used in one city and then online from a distant country minutes later is a strong sign that the card details were stolen.
Session and token theft
A stolen session cookie or token replayed from somewhere else shows up as the same account suddenly acting from a new place.
How a velocity check works
Distance divided by time
A geo-velocity check takes the location and time of the previous event and of the new one, computes the distance between them, divides by the time elapsed and compares the implied speed with a threshold.
The threshold is usually set somewhat above the speed of a commercial jet, so that genuine flights pass and physically impossible pairs do not. When the implied speed is over the threshold, the new event is flagged for a challenge or a denial.
Worked example: New York, then Berlin
Event 1 New York 12:00:00 Event 2 Berlin 12:01:30 Distance ~6,400 km Time 90 s = 0.025 h Speed 6,400 / 0.025 ≈ 256,000 km/h Airliner ~900 km/h Result over threshold → flag
The weak spot
Why IP-based impossible travel alerts misfire
Most impossible travel alerts estimate location from IP addresses. The math is right, but the inputs are not, so security teams drown in false positives and still miss attackers who use a local IP.
VPNs and proxies
An employee who connects to a corporate VPN in another country appears to jump across the world in seconds. An attacker who uses a proxy near the victim appears to stay put.
Mobile carrier IP addresses
Phones on cellular data often reach the internet through a carrier gateway far from where the user is standing. Switching between Wi-Fi and mobile data can look like a long-distance trip.
Cloud egress and shared gateways
Traffic routed through cloud services, security gateways or remote desktops leaves from a data center, not from the user's location, so two honest requests can geolocate to different regions.
Measure the person, not the network. The phone the user carries is a far better proxy for where they are than the IP address a request happens to leave from. That is the idea behind location-based authentication.
Spriv's approach
Impossible travel detection on the phone's location
Spriv's US Patent 9,727,867, "Analyzing distance and speed between the mobile phone location and a second location", applies the velocity check to the phone rather than to an IP address.
STEP 01
Record location and time
Spriv checks the location and time of the user's phone when a login or transaction is verified.
STEP 02
Compare the next attempt
When a second transaction is attempted, Spriv compares the distance between the two locations and the speed needed to travel between them.
STEP 03
Flag above the threshold
If the required speed is above the threshold, the attempt is flagged, automatically and in real time, on the second channel.
Out-of-band by design. The check runs on a separate channel from the login it protects, so an attacker who controls the browser session cannot quietly tamper with it. Read the patents.
When a flag fires
What happens after impossible travel is detected
Challenge the user
The attempt is not approved silently. The user gets a challenge such as an Allow / Deny prompt showing the username, IP address and server name, or another method you choose.
Deny the attempt
If the user does not recognize the request, they deny it. Administrators can also set an account to Deny or Locked in the management portal.
Feed the risk decision
Speed is one signal among geographic location, device reputation, login history, behavioral patterns, time of access and network characteristics. Risk based MFA.
Protect transactions too
The same check applies after login, to payments, transfers and other high-risk actions. Transaction authentication.
Questions
Impossible travel detection questions
What is a velocity check?
A velocity check divides the distance between two events by the time between them. If the implied speed is higher than a person could travel, the second event is treated as suspicious.
Is impossible travel the same as geo-velocity?
Yes, the terms are used interchangeably. Geo-velocity describes the calculation, and impossible travel describes the result when the speed is physically impossible.
Will Spriv flag my users when they fly?
A real flight moves the phone with the user, at a speed a person can actually travel. Logging in from a new place is still a new location, so the user may see a challenge on arrival, which they can approve.
Does Spriv share where my users are?
No. Spriv confirms that locations align and flags impossible combinations, but it never shares the phone's actual location, and no personally identifiable information is transferred.
Explore
Related pages
Checkit!
Catch impossible travel on the second channel
Two free users and two free servers, no credit card. Install in under five minutes and let the phone's location do the checking.