Fehlalarme bei unmöglicher Reise: VPNs, Timing und Standortdaten

Die Berechnung hinter dem Wert

POST /v1/risk/check berechnet die Großkreisdistanz zwischen dem zuvor gespeicherten Standort einer Nutzerin oder eines Nutzers und dem aktuellen, teilt sie durch die seit dieser vorherigen Beobachtung verstrichene Zeit und klassifiziert die implizierte Geschwindigkeit: unter 500 km/h ist low, 500–900 km/h ist medium, über 900 km/h ist high (impossibleTravel: true). Ein echter Langstreckenflug kann nahe an der Grenze zwischen medium und high landen, weshalb die Schwellenwerte als Bereiche und nicht als einzelner Grenzwert definiert sind — die Berechnung selbst kennt aber keinen Begriff von „Flug“, „VPN“ oder „gemeinsam genutztem Netzwerk“; sie sieht nur zwei Punkte und eine Dauer.

Die erste Beobachtung wird nie markiert

Die allererste Prüfung einer Nutzerin oder eines Nutzers hat nichts zum Vergleich: Sie liefert immer risk: "low" mit einem null-previousLocation und null-Werten für Distanz/Geschwindigkeit/verstrichene Zeit und wird (sofern nicht commit: false gesetzt ist) zur neuen gespeicherten Baseline. Das bedeutet, dass der allererste Login von einem neuen Gerät oder Netzwerk aus standardmäßig Vertrauen herstellt — gut zu wissen, wenn die erste Aktion eines Angreifers aus demselben strukturellen Grund ebenfalls unmarkiert bleibt.

Situationen, die häufig einen Fehlalarm auslösen

Der Wechsel von VPN-Exit-Knoten oder Mobilfunk-Gateways zwischen Logins kann den aufgelösten Standort über eine große Distanz verschieben, ohne dass eine reale Reise stattgefunden hat — v1 hat keine VPN- oder rechenzentrumsbewusste Unterdrückung, sodass sich das identisch zu echter unmöglicher Reise liest. Gewöhnlicher IP-Wechsel bei Mobilfunknetzen (derselbe physische Standort löst bei unterschiedlichen Anfragen zu einer anderen Gateway-Stadt auf) und gemeinsam genutzte/Anycast-IP-Bereiche können denselben Effekt erzeugen. Keine dieser Situationen betrifft einen Angreifer; es sind Artefakte davon, wie aus IP abgeleitete Standortbestimmung funktioniert — ausführlicher behandelt im Genauigkeitsartikel.

Was ein hoher Wert nicht beweist

risk: "high" ist ein reines Signal aus einer Distanz-über-Zeit-Berechnung — kein verifiziertes Kontoübernahme-Ereignis, kein Beleg dafür, wer den Login veranlasst hat, und keine Information darüber, ob die Zugangsdaten der Nutzerin oder des Nutzers tatsächlich kompromittiert wurden. Behandeln Sie es als eine Eingabe für Ihre eigene Prüf- oder Step-up-Authentifizierungsentscheidung, kombiniert mit Authentifizierungsbelegen, die Sie bereits haben, nicht als eigenständiges Urteil, auf das Sie allein reagieren.

Ein Beispiel mit zwei Beobachtungen

Die gespeicherte Baseline einer Nutzerin oder eines Nutzers ist Toronto, beobachtet um 09:00 UTC. Ein Login trifft von einer IP ein, die zu Frankfurt um 09:45 UTC auflöst — rund 6.400 km in 45 Minuten, eine implizierte Geschwindigkeit weit über 900 km/h, sodass dies risk: "high" und impossibleTravel: true liefert. Dieses Ergebnis ist sowohl mit einem kompromittierten Konto vereinbar, das von einem anderen Kontinent aus genutzt wird, als auch damit, dass der Traffic derselben legitimen Nutzerin oder desselben legitimen Nutzers plötzlich aus einem unabhängigen Grund über einen Frankfurter VPN-Exit geroutet wird — die API liefert in beiden Fällen dieselbe Einstufung, weshalb sie genau deshalb als eine Eingabe für die Prüfung konzipiert ist, nicht als automatische Sperre.

Was dieser Artikel nicht behauptet

Dies beschreibt die eigene v1-Implementierung von Watch-IP. Es behauptet keine umfassende Erkennung von Kontoübernahmen, keine Verhaltensanalyse und kein Geräte-Fingerprinting — das sind andere Techniken, die dieser Endpoint nicht versucht. Verfügbarkeit und eigenständige Durchsetzung einer Risiko-Tariffamilie für diesen Endpoint sind nicht bestätigt; kontaktieren Sie uns, bevor Sie sich in der Produktion darauf verlassen.

Quellen

• Großkreisdistanz — die von diesem Endpoint verwendete Distanzberechnung