Two Logins Too Far Apart: Impossible-Travel Detection
The challenge
Brightmoor's dashboard sign-ins all succeeded this morning, every one with the right password and no failures to catch the eye. That is the trouble: a stolen password produces a perfectly clean success. The only thing a valid login cannot fake is being in two places at once. One account signed in from its usual city and, a couple of minutes later, from the other side of the world, then back. Read the sign-in log and name the compromised account.
What you'll learn
- Explain why a stolen password produces only clean successes
- Use geolocation over time, not success/fail, as the signal
- Spot an account whose city jumps an infeasible distance in minutes
- Separate the real user's sessions from the interleaved attacker's
- List the defences: MFA, impossible-travel alerts, session binding
Skills tested
Prerequisites
- Reading tabular log events
- Rough world geography
How it works
Once an attacker has a valid password, their logins succeed exactly like the owner's. Counting failures or lockouts finds nothing, because there are none.
What a valid credential cannot fake is location. The same account cannot sign in from two cities thousands of miles apart within minutes. Correlating each account's successive sign-in locations against the time between them surfaces a distance no real journey could cover.
Here one account alternates between its home city and a city on the other side of the world, minutes apart. Those far sessions are the attacker, interleaved with the genuine user who never left home.
Common mistakes
- Looking for failed logins. Every row succeeded; the attack hides in clean successes.
- Flagging an account that simply has a different home city. Being in Accra or Lisbon is fine; jumping between cities minutes apart is not.
- Answering the attacker city or IP. The question asks which account was compromised.
- Missing the interleaving. The real user keeps working from home between the attacker's sessions, which is why both cities appear for one account.
How to defend against it
Make a password alone insufficient and watch for teleporting sessions.
- Require multi-factor authentication, so a stolen password does not grant access.
- Run impossible-travel detection: flag or step up when an account's successive logins exceed feasible travel speed.
- Bind sessions to device and network signals so an existing session cannot be resumed from a new country, and alert on first sign-in from a new country.