# Detecting Impossible Travel with IPinfo’s Core service

**URL:** <https://community.ipinfo.io/t/detecting-impossible-travel-with-ipinfo-s-core-service/6938>\
**Category:** General\
**Tags:** api, ipinfo-core\
**Created:** [July 21, 2025, 6:24pm UTC](https://community.ipinfo.io/t/detecting-impossible-travel-with-ipinfo-s-core-service/6938 "2025-07-21T18:24:09Z")\
**Posts on this page:** 1\
**Showing post:** 1

<div class="post-metadata">

**Author:** ![Abdullah](https://yyz1.discourse-cdn.com/flex035/user_avatar/community.ipinfo.io/abdullah/32/4973_2.png) [@Abdullah](https://community.ipinfo.io/u/Abdullah)\
**Post date:** [July 21, 2025, 6:24pm UTC](https://community.ipinfo.io/t/detecting-impossible-travel-with-ipinfo-s-core-service/6938/1 "2025-07-21T18:24:10Z")

</div>

# Detecting Impossible Travel with IPinfo’s Core

 ![Detecting Impossible Travel with IPinfo](https://canada1.discourse-cdn.com/flex035/uploads/ipinfo/original/2X/a/a55971d253f9b0d67bde5706e21110588326f193.png)

In cybersecurity, _impossible travel_ is an anomaly detection technique used to identify suspicious access behavior. It flags situations where a user appears to log in from two geographically distant locations within a time window too short to permit physical travel between them. This often indicates credential compromise, session hijacking, or misuse of anonymity infrastructure like VPNs or residential proxies.

By combining [geolocation intelligence](https://ipinfo.io/products/ip-geolocation-api)  
with network type indicators and timestamp analysis, organizations can establish a robust model to flag and investigate such anomalies. In this article, we walk through how to detect impossible travel events using the [IPinfo Core API](https://ipinfo.io/core) and incorporate factors such as travel speeds, time zones, and network infrastructure.

* * *

## Understanding the Concept of Impossible Travel

Consider a scenario:

- An employee logs in from **London at 09:00 AM GMT**
- The same account logs in from **San Francisco at 10:15 AM GMT**

Given that the average commercial flight speed is **900 km/h** (560 mph), and the two cities are approximately **8,600 km** apart, this would require at least **10 hours** of travel time, not accounting for airport procedures or connection delays. Since the two login events are separated by only **1 hour and 15 minutes** , the second login is physically implausible and potentially malicious.

* * *

## Common Human Travel Speeds

To assess plausibility, we consider average travel speeds:

| Mode | Typical Speed |
| --- | --- |
| Walking | ~5 km/h |
| Car | ~80–120 km/h |
| High-speed rail | ~250–300 km/h |
| Commercial Jet | ~850–900 km/h |

Using these values, we can derive a minimum plausible time threshold based on distance. Any login sequence that violates these thresholds is a strong candidate for an impossible travel alert.

* * *

## Modeling Time Constraints with IPinfo

IPinfo provides accurate geolocation and network infrastructure data for any IP address. Using the Core API, we can:

- Retrieve the **latitude** , **longitude** , and **timezone** of each login
- Calculate the **distance** between login events
- Assess if the travel between locations is possible given the **elapsed time**
- Identify **network infrastructure** anomalies such as access from hosting providers or VPN endpoints

* * *

## Sample API Usage

```bash
curl https://api.ipinfo.io/lookup/<log_ip>?token=$TOKEN

```

### Sample Response:

```json
{
  "ip": "8.8.8.8",
  "geo": {
    "city": "Mountain View",
    "region": "California",
    "region_code": "CA",
    "country": "United States",
    "country_code": "US",
    "continent": "North America",
    "continent_code": "NA",
    "latitude": 37.4056,
    "longitude": -122.0775,
    "timezone": "America/Los_Angeles",
    "postal_code": "94043"
  },
  "as": {
    "asn": "AS15169",
    "name": "Google LLC",
    "domain": "google.com",
    "type": "hosting"
  },
  "is_anonymous": false,
  "is_anycast": true,
  "is_hosting": true,
  "is_mobile": false,
  "is_satellite": false
}

```

Key fields used in impossible travel detection:

- `geo.latitude` and `geo.longitude` – for calculating distance
- `geo.timezone` – to normalize login times to UTC
- `as.type`, `is_hosting`, `is_anonymous` – to detect non-employee networks

* * *

## Step-by-Step Model for Impossible Travel Detection

1. **Log Ingest** : Collect login records with IP, timestamp, and user ID.

2. **Geolocation Resolution** : Use IPinfo Core API to resolve IPs to:

3. **Timestamp Normalization** :

4. **Distance Calculation** :

5. **Speed Estimation** :

6. **Threshold Check** :

7. **Network Flag Assessment** :

* * *

## Incorporating Work Hours and Time Zones

Employees typically log in during expected work hours (e.g., 08:00–18:00 local time). By combining timezone offsets from IPinfo’s response with user profiles or HR data, organizations can:

- Align login activity with expected work schedules
- Detect sudden shifts in timezone (e.g., user logs in from New York, then 30 minutes later from Singapore during Singapore’s night hours)

* * *

## Example Use Case

| Timestamp (UTC) | IP Address | Location | Source Type | User |
| --- | --- | --- | --- | --- |
| 2025-07-20T08:00:00Z | 203.0.113.5 | Paris, France | Residential | Alice |
| 2025-07-20T09:00:00Z | 8.8.8.8 | California, USA | Hosting | Alice |

Using the IPinfo Core API, we determine:

- **Distance** : ~9,000 km
- **Time elapsed** : 1 hour
- **Required speed** : 9,000 km/h

Result: **Flagged as impossible travel**

- Additionally, second IP is from a **hosting provider** , which is suspicious for user-based login.

### Breakdown of Key Network Flags

| Flag | Description | Impact on Accuracy | Implications for Impossible Travel |
| --- | --- | --- | --- |
| `is_anonymous` | Indicates usage of anonymity services such as VPNs or proxies. | Typically geolocates to data center or exit node, not the end user. | Travel anomalies from such IPs should be treated with caution or discounted. |
| `is_anycast` | The IP is advertised from multiple global locations. | Location may vary depending on routing and may not be user-specific. | Suggests automated, bot, or unauthorized remote access rather than human logins. |
| `is_hosting` | Associated with cloud providers or hosting facilities. | Usually maps to server locations, not real users. | Suggests automated, bot, or unauthorized remote access rather than human logins. |
| `is_mobile` | Assigned to mobile carriers or cell networks. | Often geolocates to central routing locations; may resolve only to city or region level. | Reduced precision; legitimate user movement may appear faster than possible. |
| `is_satellite` | Linked to satellite internet providers. | Tends to be roughly accurate at a large-city or metro area scale, but not exact. | Travel detection should account for ~50–100km radius tolerance. |

* * *

Impossible travel detection is an effective technique for flagging compromised credentials and unauthorized access. By using the [IPinfo Core](https://ipinfo.io/core), security teams can go beyond IP geolocation and tap into network infrastructure intelligence — identifying whether logins originate from VPNs, hosting providers, or anonymizing services.

This model works best when combined with behavior baselines, work hour profiles, and additional authentication triggers. With accurate data and a clear set of rules, impossible travel becomes a powerful line of defense in modern identity security.

---

_[View the full topic](https://community.ipinfo.io/t/detecting-impossible-travel-with-ipinfo-s-core-service/6938)._