Been meaning to write this one up for a while. Kept reading explanations of the same idea, distance between two logins divided by time, flag it if the implied speed is impossible, probably the fifth or sixth version of that exact explanation across different security blogs. Good idea, explained constantly. Never saw anyone actually ship the code for it, just the concept, again. So I built it instead of reading a seventh explainer.
Saw the fail2ban thread here a while back (the Cloudflare + fail2ban combo discussion especially) and it’s a good contrast for what this is actually doing. Fail2ban watches for repeated failed logins from the same IP and bans it, which handles brute force well. It has nothing to say about a single successful login using valid, stolen credentials from a location that makes no physical sense. There’s no repeated failure for it to catch, the password was right on the first try. Different failure mode entirely, and one that’s easy to miss if fail2ban is doing the heavy lifting on the login-security side already.
The actual logic:
- Store the location and timestamp of a user’s last login
- On the next login, work out the distance from the last one (haversine, not straight-line, since it needs to account for the curve of the earth over long distances)
- Divide by elapsed time to get an implied speed
- Flag it if that speed is something no commercial flight could match
What made this worth finishing instead of leaving as a gist:
- Zero runtime dependencies, small enough to actually read in one sitting
- Pluggable storage interface, so it drops into whatever you’re already running (Redis, Postgres, whatever) instead of assuming a specific stack
- Handles the annoying edge cases: first login for a user is never flagged (nothing to compare yet), and there’s a minimum distance floor so IP jitter within the same city doesn’t cause constant false positives
- MIT licensed, free, no paid tier
Rough flow: store lat/long + timestamp on login → next login, compute distance and elapsed time → flag if implied speed clears the threshold → step-up verification, not a hard block, real users hop networks more than you’d expect.
There’s a live demo if you want to see the logic before installing anything, pick two cities and a time gap and it’ll flag or clear right in the browser: Impossible Travel Check — Try It Live
Code’s here if you want to run it yourself: GitHub - Furqan-Ashraf/impossible-travel-guard, also on npm as impossible-travel-guard.
Wrote a longer technical walkthrough with the full code and the false-positive handling in more depth here, if useful: Detect Account Takeover in Node.js: A Free Login Location Check - DEV Community
(For sourcing the lat/long itself, any IP geolocation provider works, I used IPGeolocation.io’s free tier since I already had it handy, but the library doesn’t care what you use.)
Curious if anyone here is running something similar server-side already, or layering geo-velocity checks into fail2ban jails somehow. Feels like there’s a way to combine the two (fail2ban for the noisy brute-force layer, this for the quiet single-successful-login layer) but I haven’t tried wiring them together yet.