Geovelocity Checks

The foundational geometric formula that computes the great-circle distance between two latitude/longitude coordinate pairs on a sphere. Unlike simple Euclidean distance, the haversine formula accounts for the Earth's curvature, providing accurate kilometer-level measurements essential for calculating the minimum travel distance between login events. This calculation ignores terrain and infrastructure, representing the absolute theoretical minimum path.

The core computation divides the haversine distance by the time delta between two sequential events to derive a required speed. This speed is compared against a configurable threshold, typically the maximum speed of commercial aviation (approx. 900-1,000 km/h). The engine must account for clock synchronization issues, timezone offsets, and network latency to avoid false positives caused by timestamp inaccuracies rather than genuine fraud.

Static speed limits generate high false positive rates. Advanced geovelocity engines implement contextual thresholding that dynamically adjusts acceptable speeds based on:

• User tier: VIP travelers vs. local-only accounts
• Historical patterns: Frequent flyers have higher baseline velocities
• Event type: Login vs. high-value transaction vs. password change This prevents locking out legitimate business travelers while maintaining strict checks on sensitive actions.

Geovelocity is rarely used in isolation. A true impossible travel detection system correlates velocity anomalies with other signals:

• Device fingerprint mismatch: Same credentials, new device
• Behavioral biometric drift: Typing cadence or mouse dynamics change
• IP reputation: Known proxy, VPN, or TOR exit node
• Time-of-day anomalies: Access at 3 AM local time This correlation transforms a single velocity flag into a high-confidence account takeover score.

Production systems must gracefully handle scenarios that break naive velocity calculations:

• VPN/Proxy passthrough: Apparent location is the exit node, not the user
• GPS spoofing: Injected fake coordinates from emulators
• Missing location data: Fallback to IP geolocation when GPS is unavailable
• Multi-device sessions: Legitimate user on phone and laptop simultaneously Robust implementations degrade gracefully, assigning lower confidence scores when location data quality is poor.

The output of a geovelocity check feeds directly into a risk-based authentication engine that triggers proportional responses:

• Low risk: Silent logging for future analysis
• Medium risk: Step-up authentication (MFA challenge, biometric verification)
• High risk: Session termination and account lockout
• Critical risk: Real-time alert to SOC analysts This graduated response model balances security with user experience, avoiding blanket denials for borderline velocity calculations.

The process of identifying traffic originating from a Virtual Private Network by cross-referencing IP addresses against known VPN exit node databases and analyzing network stack artifacts. VPNs mask a user's true geolocation, which can defeat naive geovelocity checks. Advanced detection examines TCP/IP fingerprinting, DNS leak analysis, and latency triangulation to unmask anonymized connections.

• Data Sources: Commercial IP intelligence feeds (MaxMind, IP2Location)
• Artifacts: Mismatched timezone vs. browser locale, WebRTC leaks
• Integration: VPN score feeds directly into risk-based authentication engines

An adaptive security framework that dynamically adjusts authentication requirements based on a real-time risk score. Geovelocity violations contribute a high-risk signal to the RBA engine. If the calculated travel speed is implausible, the system may step-up authentication to require a one-time password, biometric verification, or outright block the session.

• Input Signals: Geovelocity, device fingerprint, behavioral biometrics, IP reputation
• Actions: Allow, step-up MFA, block, or initiate silent verification
• Goal: Balance security with user friction

The identification of an attack where a valid user session is compromised, typically through stolen session cookies or tokens. Geovelocity checks are critical here: an abrupt change in the geolocation of an existing, authenticated session—without a corresponding login event—is a strong signal of session hijacking. The system detects a spatial discontinuity that violates physical travel constraints.

• Signal: Session origin shifts from Chicago to Moscow within seconds
• Response: Invalidate session token, force re-authentication
• Complement: Combine with device fingerprint delta checks

The identification of traffic routed through The Onion Router anonymity network by checking IP addresses against public TOR exit node lists. TOR exit nodes frequently rotate and can appear globally distributed, causing legitimate users to exhibit impossible travel patterns. Detection allows the system to adjust geovelocity thresholds or apply stricter verification for TOR-originated sessions.

• Data Source: Public TOR exit node list (https://check.torproject.org)
• Challenge: High false-positive rate for privacy-conscious legitimate users
• Strategy: Flag as high-risk rather than outright block

A passive identification technique that collects a multitude of attributes from a remote computing device to generate a unique identifier. When paired with geovelocity, device fingerprinting provides corroborating evidence: if the geovelocity check flags an impossible travel event, but the device fingerprint matches the user's known device, the risk score may be moderated. Conversely, a new device plus impossible travel is a critical alert.

• Attributes: Browser version, OS, installed fonts, screen resolution, canvas hash
• Correlation: Same device + impossible travel = possible VPN usage
• Correlation: New device + impossible travel = likely account takeover