Silent Network Authentication: Betrugssichere Anmeldung mit FastAPI + Kotlin

Machen Sie Ihren Python-Checkout in FastAPI betrugssicher. 

Betrug ist längst keine Aufgabe mehr, die im Backoffice nachbearbeitet wird. Es ist eine Entscheidung, die Ihr Authentifizierungscode innerhalb von 200 Millisekunden trifft – oder die Angreifer für Sie treffen. Dieses Tutorial führt einen Python-Backend-Entwickler durch die beiden netzbetreiberseitigen Signale, die die Lücke schließen, die SMS-OTP offen gelassen hat: SIM-Swap-Erkennung und stille Netzwerkauthentifizierung – beides integriert in eine funktionierende FastAPI-App, die Sie noch am selben Tag Ihrem technischen Leiter vorlegen können. Lies weiter, um mehr über Betrug und Account-Übernahmen zu erfahren, oder springe direkt zum Einrichten und Ausführen des Codes mithilfe der README. 

Warum das wichtig ist: Betrug durch Account-Übernahme verursacht mittlerweile jährliche Verluste in achtstelliger Höhe für Fintech-Unternehmen des Mittelstands und bedeutet für die dahinter stehenden Entwicklerteams einen Supportaufwand im zweistelligen Prozentbereich. Die beiden wirksamsten Schutzmaßnahmen, die Sie heute in einen Python-Anmeldeablauf integrieren können, sind die SIM-Swap-Erkennung (hat sich die SIM-Karte unter dieser Nummer in den letzten 7 Tagen geändert?) und die stille Netzwerkauthentifizierung (ist dies gerade jetzt die tatsächliche SIM-Karte im tatsächlichen Mobilfunknetz für diese Nummer?). Beide laufen auf Seiten des Netzbetreibers. Beide sind über die Vonage-Netzwerk-APIs zugänglich. Bei keiner der beiden muss der Nutzer etwas eingeben. 

Was kommt als Nächstes: Nach diesem Tutorial bündelt Ihr FastAPI-Backend „SIM Swap“ und „Silent Auth“ in einer einzigen Anmelderoute, greift nur dann auf die Verification per SMS-OTP zurück, wenn der Netzwerkpfad nicht abgeschlossen werden kann, und verfügt über die für den Produktionsbetrieb erforderlichen Sicherheitsvorkehrungen (Timeout-Fallback, auf „Fail-Closed“ ausgerichtete Standardeinstellungen, Observability-Hooks), die Sie benötigen, bevor Sie echten Datenverkehr darauf leiten. End-to-End-Betrugsprävention ist kein separates System mehr, das integriert werden muss, sondern besteht aus zwei API-Aufrufen innerhalb des Authentifizierungsablaufs, den Sie bereits nutzen.

Der kostspielige Anstieg von Betrugsfällen und Account-Übernahmen

Möchten Sie Ihren Account-Stand überprüfen? Kein Problem! Melden Sie sich einfach mit Ihrer E-Mail-Adresse und Ihrem Passwort im Online-Banking-Portal an. Und dann – nur um sicherzugehen, dass Sie es wirklich sind – wird eine SMS mit einem Einmalpasswort (OTP) an die bei uns hinterlegte Handynummer gesendet. Wenn Sie es tatsächlich sind, der sich anmelden möchte, geht man davon aus, dass Sie dieses Handy gerade in der Hand halten. Stimmt der von Ihnen eingegebene Code mit dem vom Verifizierungsverfahren generierten überein, werden Sie authentifiziert und erhalten Zugriff auf Ihr Geld. 

Was aber, wenn die Person, die diese SMS erhält, nicht du selbst bist? Was, wenn jemand dein Handy gestohlen hat? Was, wenn jemand sich in dein E-Mail-Konto gehackt hat? Was, wenn der Anmeldeversuch von jemandem initiiert wurde, der mit einem Bot und einer Liste von Benutzernamen und Passwörtern kompromittierter Accounts arbeitet, die er „Credential Stuffing“? 

Account-Übernahme ist eine Art von Betrug, bei der sich ein Angreifer Zugang zu einem Account verschafft, dessen rechtmäßiger Inhaber er nicht ist. Eine Account-Übernahme ist in der Regel die Folge eines Authentifizierungsfehlers. Ein Authentifizierungsfehler tritt auf, wenn ein Angreifer ein System dazu verleitet, einen ungültigen oder falschen Benutzer als legitim anzuerkennen. Authentifizierungsfehler gehören nach wie vor zu den die zehn größten Anwendungssicherheitsrisiken des Open Web Application Security Project (OWASP) und steht bereits das fünfte Jahr in Folge. 

Betrug durch Kontoübernahme führte im Jahr 2023 zu Verlusten in Höhe von fast 13 Milliarden US-Dollar, was einen Anstieg gegenüber den 11 Milliarden US-Dollar im Jahr 2022 darstellt. Die finanziellen Kosten allein sind nicht die einzige Gefahr, die von Betrug und Schwachstellen bei der Anwendungsauthentifizierung ausgeht; der Schaden für das Vertrauen in die Marke und den Ruf ist noch kostspieliger.

Fraud is no longer a back-office cleanup job.

Auch wenn Betrug wahrscheinlich nie ganz ausgerottet werden kann, gibt es Strategien, die Sie umsetzen können, um zusätzliche Überprüfungs- und Sicherheitsstufen zu schaffen und die Übernahme von Accounts zu verhindern. In diesem Blogbeitrag werden wir diese Strategien erörtern und anschließend eine Beispielanwendung (Android-Client mit FastAPI Server) sowie Codeausschnitte, um zu veranschaulichen, wie Vonage Verify Ihre Authentifizierungsabläufe durch SIM-Swap-Prüfungen, stille Authentifizierung und den Rückgriff auf alternative Verifizierungsmethoden sichern kann. 

Sie können sich den Code für die in diesem Blogbeitrag enthaltene Demo-Anwendung ansehen und diese gemäß der README. 

Was ist „Silent Network Authentication“ und warum ersetzt sie SMS-OTP?

Wurden Sie schon einmal gehackt? Die Wahrscheinlichkeit ist groß, dass dies der Fall ist. Im Dezember 2025 deckte das US-amerikanische Federal Bureau of Investigations 630 Millionen kompromittierte Passwörter auf verschiedenen Geräten eines einem einzigen Hacker. Die Folgen davon sind weitreichend, vor allem aber verdeutlicht dies, wie unsicher das Protokoll mit Benutzername und Passwort mittlerweile geworden ist.  

Die Multi-Faktor-Authentifizierung (MFA) und die Zwei-Faktor-Authentifizierung (2FA) bieten einen zusätzlichen Schutz vor dem Diebstahl von Anmeldedaten, da für den Zugriff auf ein System die Vorlage von mehr als einer Art von Identitätsnachweis erforderlich ist. Einmal-Passwörter (OTP) per SMS sind eine Form der 2FA, die auf dem „Etwas, das Sie besitzen“ – also einen auf dem Besitz basierenden Nachweis nutzt, mit dem Sie nachweisen können, dass Sie der sind, für den Sie sich ausgeben. Aufgrund der weit verbreiteten Nutzung von Mobiltelefonen gehören SMS-OTPs zu den am häufigsten eingesetzten Methoden der MFA. 

Leider da der weit verbreiteten Nutzung von SMS-OTPs haben Betrüger Strategien entwickelt, um diese Methode der MFA zu umgehen und zu untergraben, wie zum Beispiel: 

• Netzwerküberwachung nach dem Signalisierungssystem 7 (SS7): Eine Protokollschwachstelle auf Netzbetreiberebene, die es Angreifern ermöglicht, SMS-Nachrichten an sich selbst umzuleiten 

• SIM-Swap: Ein Angreifer nutzt Social Engineering, um den Mobilfunkanbieter dazu zu bringen, die Rufnummer des Opfers einer neuen SIM-Karte zuzuweisen 

• Phishing: Der Nutzer wird dazu verleitet, das OTP auf einer gefälschten Anmeldeseite einzugeben 

Stille Netzwerkauthentifizierung (SNA) – kurz „Silent Authentication“ – ist eine netzbetreiberseitige, auf dem Besitz basierende Überprüfung, bei der die mobile Datensitzung eines Mobiltelefons über das Netz des Betreibers umgeleitet wird, ohne dass Sie einen Code eingeben müssen. Dadurch entfällt die Abhängigkeit von einem externen Faktor (wie einem Angreifer) zur Verification Ihrer Identität. 

Die „Silent Network Authentication“ Verifies, ob das Gerät, das gerade die mobile Datensitzung nutzt, auch tatsächlich der Inhaber der Telefonnummer ist – ohne dass ein Code versendet wird. Dies geschieht durch die Umleitung einer vom Netzbetreiber verifizierten HTTP-Anfrage über den Betreiber. Im Gegensatz zu SMS-OTP schließt sie den SS7-Angriffsvektor; sie schützt jedoch allein nicht vor SIM-Swap-Angriffen – um dieses Risiko zu minimieren, sollte zusätzlich zur stillen Authentifizierung eine SIM-Swap-Prüfung durchgeführt werden. Mit der Vonage Verify API können Sie ein Python-FastAPI-Backend und einen mobilen Client nutzen, um die stille Authentifizierung zu implementieren und Ihre Applications weiter zu sichern. 

Was ein SIM-Swap-Angriff ist und wie man sich dagegen schützen kann

Ein SIM-Swap-Angriff ist eine Form des Betrugs durch Kontoübernahme, die auf bestimmte Schwachstellen abzielt, die dem MFA per SMS-OTP. Bei dieser Art von Angriff wird ein Mobilfunkanbieter dazu verleitet, eine neue SIM-Karte zu aktivieren, die das Netz des Anbieters dann mit der Telefonnummer des Opfers verknüpft. Der Inhaber der Nummer ändert sich nicht; der Angreifer erhält jedoch Zugriff auf eingehende SMS und Voice-Anrufe, die mit dieser Nummer verbunden sind, solange der Austausch unentdeckt bleibt. Um einen SIM-Swap-Angriff durchzuführen, sammelt ein Angreifer persönliche Daten über Sie, entweder durch Phishing-Betrug, über Schwarzmarktlisten mit gestohlenen Daten oder durch Social Engineering. Anschließend kontaktiert der Angreifer Ihren Mobilfunkanbieter und nutzt Ihre persönlichen Daten, um den Kundendienstmitarbeiter davon zu überzeugen, eine neue SIM-Karte zu aktivieren, die Ihrer Nummer zugeordnet ist. Das Gerät des Angreifers empfängt nun Ihre eingehenden SMS und Voice-Anrufe. Der Angreifer wird niemals Eigentümer der Nummer (Rechnungsadresse, Vertrag und Account bleiben bei Ihnen); er erhält lediglich Zugriff auf die Netzwerkebene, um den Datenverkehr abzufangen, bis Sie oder Ihr Mobilfunkanbieter dies bemerken. 

Das bekannteste Beispiel für einen erfolgreichen SIM-Swap-Angriff ereignete sich im Jahr 2019, als der Account des Twitter-CEO Jack Dorsey über betrügerische SMS-OTP-2FAgehackt wurde. Der Vorfall machte deutlich, dass niemand vor Betrug gefeit ist. Zudem hatte die hinter dem Hack stehende Gruppe bereits in der Vergangenheit erfolgreich Accounts mithilfe ähnlicher Methoden des Social-Engineering-basierten SIM-Swaps übernommen. Mit anderen Worten: Der Mensch bleibt das schwächste Glied in jeder Sicherheitskette. 

Abgesehen von praktischen Maßnahmen, die Sie ergreifen können, um einen SIM-Karten-Tausch zu vermeiden – wie die Verwendung von PINs, sicheren, eindeutigen Passwörtern und die Vorsicht bei der Veröffentlichung bestimmter Daten –, können Sie bei der Entwicklung von Authentifizierungsabläufen, die eine Interaktion über das Mobiltelefon erfordern, eine kurze Überprüfung des Status der SIM-Karte eines Geräts einbauen. Das Ergebnis einer solchen Überprüfung kann dann den weiteren Verlauf Ihres Authentifizierungsablaufs beeinflussen, beispielsweise durch den Rückgriff auf eine andere Form der Zwei-Faktor-Authentifizierung (2FA). 

Die Überprüfung, ob eine SIM-Karte innerhalb eines festgelegten Zeitraums ausgetauscht wurde, kann dabei helfen, ein verdächtiges Gerät zu identifizieren, alternative Authentifizierungsmethoden auszulösen und diesen häufigen Angriff abzuwehren. Mithilfe der Vonage Identity Insights API können Sie Informationen zu einer SIM-Karte abrufen, beispielsweise wann sie zuletzt ausgetauscht wurde, und auf dieser Grundlage entscheiden, wie Sie mit Ihrem Authentifizierungsablauf fortfahren. 

Was ist die Vonage Identity Insights API?

Die Vonage Number Insight API liefert in Echtzeit Informationen zu Telefonnummern direkt aus der Infrastruktur der Mobilfunkbetreiber – passiv, reibungslos und fälschungssicher. Konkret stellt sie Signale auf Betreiberebene zu einer Telefonnummer bereit, darunter Angaben dazu, ob das Format gültig ist, ob die SIM-Karte kürzlich ausgetauscht wurde, sowie weitere Indikatoren für Betrugsrisiken. Diese Signale können genutzt werden, um das Risikoniveau hinter einer bestimmten Aktion – wie beispielsweise einer Anmeldung, einer Neuregistrierung, einer Wiederherstellung des Accounts oder einer Finanztransaktion – zu bewerten. Dies ermöglicht eine adaptive Sicherheit, die den Schutz genau dann und dort verstärkt, wo er benötigt wird. Für diesen Blogbeitrag verwenden wir die „SIM-Swap-Insight“verwenden. 

Mit der SIM-Swap-Anzeige können Sie feststellen, ob die mit einer bestimmten Telefonnummer verknüpfte SIM-Karte kürzlich ausgetauscht wurde. Sie dient dazu, die Auswirkungen einer Kontoübernahme (SIM-Swap-Angriff) zu mindern, und gibt Ihnen die Gewissheit, dass die Telefonnummer für verschiedene Anwendungsfälle genutzt werden kann, beispielsweise für die SMS-2FA oder als sicherer Kommunikationskanal.

Ein typischer Aufruf des Identity Insights-Endpunkts für den SIM-Swap enthält die folgende Nutzlast:

{
    "phone_number": "14040000000",
    "purpose": "FraudPreventionAndDetection",
    "insights": {
        "sim_swap": {
            "period": 240
        }
    }
}

Dies wird im Folgenden näher erläutert:  

Weitere Informationen zur API und ihrer Funktionsweise finden Sie in der Dokumentation zu Vonage Identity Insights. 

Eine erfolgreiche Anfrage liefert als Antwort eine 200 OK und eine Sammlung der angeforderten Einblicke. Die Antwort enthält außerdem eine request_id: 

{
    "request_id": "aaaaaaaa-bbbb-cccc-dddd-0123456789ab",
    "insights": {
        "sim_swap": {
            "latest_sim_swap_at": "2024-07-08T09:30:27.504Z",
            "is_swapped": true,
            "status": {
                "code": "OK",
                "message": "Success"
            }
        }
    }
}

Anhand dieser Antwort können Sie festlegen, wie Ihr Verifizierungsablauf weitergehen soll. 

Was ist die Vonage Verify API?

Verify API ist das Produkt der nächsten Generation von Vonage für die Zwei-Faktor-Authentifizierung (2FA). Mit der Verify API können Sie Ihre Nutzer authentifizieren und Betrug verhindern – dank einer einfachen, benutzerfreundlichen API, die die Komplexität der 2FA weltweit abstrahiert.  

Sie erweitert herkömmliche Authentifizierungsmethoden durch die Unterstützung einer größeren Bandbreite an Kanälen, darunter Over-the-Top-Kanäle (OTT) wie WhatsApp sowie SMS, Voice und E-Mail. Die API unterstützt sowohl JSON Web Tokens (JWT) als auch Basic-Authentifizierung. Die Basic-Authentifizierung ist einfacher in der Handhabung, unterstützt jedoch keine erweiterten Funktionen wie ACLs. Sie können entweder die JWT- oder die Basic-Authentifizierung verwenden, jedoch nicht beide gleichzeitig. Weitere Informationen zur Authentifizierung finden Sie in der Dokumentation.  

Im Großen und Ganzen folgt die Verify API diesem Arbeitsablauf: 

1. Ein Endnutzer löst in einer Anwendung eine 2FA-Anfrage aus 

2. Im Backend löst diese 2FA-Anfrage eine Verify API-Anfrage aus 

3. Die Verify API sendet dem Endnutzer einen Einmal-Passcode (OTP) über den Kanal – oder die Kanalfolge –, den bzw. die Sie für Ihren Authentifizierungsprozess konfigurieren (SMS, Voice, WhatsApp, E-Mail und mehr), sodass Sie den Verifizierungsablauf ganz nach Ihren Anforderungen flexibel gestalten können. 

4. Der Endnutzer gibt das OTP in die Anwendung ein 

5. Dadurch wird eine Verify-Anfrage ausgelöst, um das vom Endnutzer angegebene OTP mit dem von Vonage generierten OTP abzugleichen. 

6. Das Ergebnis dieser Überprüfung bestimmt dann, wie es weitergeht (der Endbenutzer wird authentifiziert usw.)  

A visual representation of a Verify request flow with summary callbacks.Eine typische erste Verifizierungsanfrage enthält die folgende Nutzlast, wobei jede channel in der workflow Liste definiert, wohin das OTP gesendet werden soll:

{"locale": "es-es",  
   "channel_timeout": 180,  
   "client_ref": "myPersonalRef",  
   "code_length": 4,  
   "code": "e4dR1Qz",  
   "brand": "ACME",  
   "template_id": "4ed3027d-8762-44a0-aa3f-c393717413a4",  
   "workflow": [  
      { "channel": "sms",  
         "to": "44770090000"},  
      { "channel": "voice",  
         "to": "44770090000" }  
   ] } 

 Dies wird im Folgenden näher erläutert:  

Weitere Informationen zur API und ihrer Funktionsweise finden Sie in der Vonage Verify-Dokumentation.  

Eine erfolgreiche Anfrage wird mit einem 202 OK , um anzuzeigen, dass die Verifizierungsanfrage eingeleitet wurde. Die Antwort enthält außerdem eine request_id , der zum Abschluss des Verifizierungsprozesses erforderlich ist: 

{ "request_id": "c11236f4-00bf-4b89-84ba-88b25df97315"}   

Gleichzeitig sendet Vonage dem Endnutzer über den konfigurierten Workflow ein OTP und versucht dabei, jeden Kanal in der Reihenfolge zu nutzen, in der er definiert ist.  

Sobald der Endnutzer das OTP erhalten und in die Anwendung eingegeben hat, erfolgt eine weitere Anfrage an den verify Endpunkt mit dem request_id als Pfadparameter (https://api.nexmo.com/v2/verify/:request_id) und das OTP im Anfragetext für den code Schlüssel in der Nutzlast. 

Wenn der angegebene Code mit dem von Vonage generierten und gesendeten Code übereinstimmt, wird eine 200 OK wird eine Antwort zurückgegeben. 

Wie sich die „Silent Authentication“ unterscheidet

Stille Authentifizierung nutzt das Subscriber Identity Module (SIM) eines Mobiltelefons, um die Identität eines Nutzers ohne jegliche Eingabe seitens des Nutzers zu Verify. Dabei wird die Telefonnummer des Nutzers mit den Daten des Mobilfunkanbieters abgeglichen, um sicherzustellen, dass sie aktiv und gültig ist. 

Sobald eine Anfrage verifiziert wurde, können Sie den Benutzer so lange authentifizieren, bis die Anfrage entweder abläuft oder vom Benutzer abgebrochen wird. 

Um die „Silent Authentication“ in Ihren Verifizierungsprozess zu integrieren, fügen Sie sie als channel in die workflow Liste in Ihrer Anfrage-Nutzlast hinzu. Bitte beachten Sie, dass silent_auth an erster Stelle stehen muss, da der Workflow in der Reihenfolge ausgeführt wird, in der er definiert ist: 

"workflow": [
    {
        "channel": "silent_auth",
        "to": "44770090000",
        "redirect_url": "https://acme-app.com/sa/redirect",
        "check_coverage": "true"
    },
    {
        "channel": "sms",
        "to": "44770090000"
    },
    {
        "channel": "voice",
        "to": "44770090000"
    }
]

Wenn der silent_auth Kanal angegeben ist, enthält die Antwort check_url zusätzlich zu dem request_id: 

{
    "request_id": "c11236f4-00bf-4b89-84ba-88b25df97315",
    "check_url": "https://api.nexmo.com/v2/verify/c11236f4-00bf-4b89-84ba-88b25df97315/silent-auth/redirect"
}

Der Wert für check_url ist die URL, die GET wird dann auf der Client-Seite über Mobilfunkdaten ausgeführt. Es ist wichtig zu beachten, dass die stille Authentifizierung auf einer verifizierten GSM-Antwort des Geräts beruht, um dessen Anmeldedaten nachzuweisen; diese wird jedoch nicht gesendet, wenn der Nutzer mit einem WLAN verbunden ist. Der Nutzer muss daher die Authentifizierungsanfrage über Mobilfunkdaten auslösen. (Wir werden uns genauer ansehen, wie das Vonage Android SDK eine Mobilfunkverbindung erzwingen kann, wenn wir zur Client-Seite kommen.) 

Wenn der Client eine GET Anfrage an die URL erfolgreich ausführen kann, antwortet Vonage mit der request_id und eine code. 

Dieser Code wird anschließend bei einem Anruf an den verify Endpunkt überprüft, und wenn er mit dem von Vonage generierten OTP übereinstimmt, wird ein 200 OK Wert mit "status": "complete".  

Aufbau einer durchgängigen Betrugsprävention mit Python, Kotlin und Vonage

Die Beispielanwendung in diesem Blogbeitrag veranschaulicht einen minimalen Authentifizierungsablauf, der als zusätzlicher Schritt für die MFA genutzt werden könnte. Den Code finden Sie auf der GitHub der Vonage Community. Der auf Android Kotlin basierende Client kommuniziert mit einem mit FastAPI geschriebenen Backend-Server und nutzt dabei die Vonage Insights- und Verify-APIs, um einen Authentifizierungsworkflow zu definieren und auszuführen. 

Die Anwendung führt die folgende Abfolge aus: 

1. Dem Endnutzer wird ein Bestätigungsbildschirm angezeigt, auf dem er zur Eingabe seiner Telefonnummer aufgefordert wird. 

2. Die Eingabe einer Telefonnummer löst eine Übertragung an den Backend-Server aus und startet damit eine Abfolge von Verifizierungsschritten. 

3. Das Backend sendet eine Anfrage an den Insights-Endpunkt, um zu prüfen, ob die SIM-Karte innerhalb eines bestimmten Schwellenwerts ausgetauscht wurde. 

4. Wurde die SIM-Karte kürzlich ausgetauscht oder lassen sich solche Informationen nicht ermitteln, wird ein Hinweis angezeigt. 

   1. Eine als verdächtig markierte SIM-Karte kann darauf hindeuten, dass ein Gerät kompromittiert wurde. Dies beeinträchtigt die Vertrauenswürdigkeit anderer Formen der mobilgerätebasierten Verifizierung, sodass die Anwendung auf die für die angegebene Telefonnummer hinterlegte E-Mail-Adresse zurückgreift und dort mithilfe der Verify API ein Einmalpasswort (OTP) versendet. 

   2. Wenn der Endnutzer ein Einmalpasswort (OTP) erhält und eingibt, das mit dem von Vonage generierten OTP übereinstimmt, gilt er als verifiziert; stimmt das OTP nicht überein, gilt der Endnutzer als nicht verifiziert. 

5. Wenn die SIM-Karte in letzter Zeit nicht ausgetauscht wurde, wird der Arbeitsablauf mit einer stillen Authentifizierung fortgesetzt. 

6. Sollte die stille Authentifizierung fehlschlagen oder vom Netzbetreiber nicht unterstützt werden, greift die Anwendung auf die SMS-OTP zurück. 

   1. Wenn der Endnutzer ein Einmalpasswort (OTP) erhält und eingibt, das mit dem von Vonage generierten OTP übereinstimmt, gilt er als verifiziert; stimmt das OTP nicht überein, gilt der Endnutzer als nicht verifiziert. 

7. Wenn die stille Authentifizierung erfolgreich abgeschlossen wurde, gilt der Endbenutzer als verifiziert.  

Die Voraussetzungen, die Einrichtung der Umgebung und die Schritte zur Ausführung dieses Codes finden Sie in der README auf GitHub. Im Folgenden werden wir wichtige Teile des Codes ausführlich besprechen. 

Verwendung von FastAPI und dem Vonage Python SDK zur Definition des Backend-Servers

Um eine Trennung der Zuständigkeiten zu erreichen, definieren wir eine Gruppe von Funktionen, die mit Vonage interagieren, in einer Datei namens vonage_handlers.py. 

Initialisierung der Vonage-Clients

In dieser Beispielanwendung verwenden wir sowohl die Identity Insights- als auch die Verify API. Da diese leicht unterschiedliche Endpunkte haben, erstellen wir zwei Clients, um dies zu handhaben. In beiden Fällen VONAGE_APPLICATION_ID und VONAGE_PRIVATE_KEY_PATH werden von Vonage bereitgestellt, wenn Sie eine Anwendung erstellen. Die vollständige Einrichtung dieser Anwendung wird im Repo READMEbeschrieben. 

verify_client = Vonage(
    Auth(
        application_id=os.environ["VONAGE_APPLICATION_ID"],
        private_key=os.environ["VONAGE_PRIVATE_KEY_PATH"],
    )
)

identity_insights_client = Vonage(
    Auth(
        application_id=os.environ["VONAGE_APPLICATION_ID"],
        private_key=os.environ["VONAGE_PRIVATE_KEY_PATH"],
    ),
    http_client_options={"api_host": "api-eu.vonage.com"},
)

SIM-Swap-Prüfung

Zunächst überprüfen wir den Status der SIM-Karte, die mit der vom Endnutzer an den Kunden übermittelten Nummer verknüpft ist, und geben True, False, oder None: 

def check_sim_swap(phone: str) -> bool | None:
    """
    Returns True if SIM was swapped, False if not, None if carrier doesn't permit check.
    """
    insights_request = IdentityInsightsRequest(
        phone_number=phone,
        purpose="FraudPreventionAndDetection",
        insights=InsightsRequest(
            format=EmptyInsight(), sim_swap=SimSwapInsight(period=240)
        ),
    )
    return identity_insights_client.identity_insights.requests(
        insights_request
    ).insights.sim_swap.is_swapped

Diese Funktion ruft den Identity Insights-Endpunkt auf und gibt die SIM-Swap-Informationen für die vom Endnutzer angegebene Nummer an den Client zurück. 

Den Prozess zur stillen Authentifizierungsüberprüfung initialisieren

Wir initialisieren den Verifizierungs-Workflow mit der start_silent_auth Funktionsaufruf: 

def start_silent_auth(phone: str) -> dict:
    """
    Starts Silent Auth verification.
    Returns channel, request_id, and check_url.
    Raises HttpRequestError with 412 if Silent Auth unavailable.
    """
    request = VerifyRequest(
        brand="DemoApp", workflow=[SilentAuthChannel(to=phone)], coverage_check=True
    )
    response: StartVerificationResponse = verify_client.verify.start_verification(
        request
    )
    return {
        "channel": "silent_auth",
        "request_id": response.request_id,
        "check_url": response.check_url,
    }

Wir fügen den coverage_check Parameter ein, um synchron zu prüfen, ob das Zielnetzwerk des Endnutzers von der Silent Authentication unterstützt wird. Ist dies nicht der Fall, gibt Vonage eine 4xx Antwort zurück. Diese erste Überprüfung verhindert Verzögerungen, die durch unnötige Umleitungsabläufe entstehen könnten. Anstatt mehrere GET Versuche zu unternehmen, kann Ihre Anwendung auf eine andere Verifizierungsmethode ausweichen, falls „Silent Authentication“ das Netz des Netzbetreibers des Endnutzers nicht unterstützt. Dies kann zu einer besseren Benutzererfahrung führen. 

Wenn das Netzwerk des Endnutzers „Silent Authentication“ unterstützt und die GET Anfrage über die check_url von Vonage bereitgestellte Anfrage erfolgreich ist, dann wird eine request_id und code . Dieser Code wird in einer anderen Funktion überprüft. 

Ausweichmöglichkeiten bei alternativen OTP-Verfahren

Je nach Ergebnis der SIM-Swap-Prüfung und des Versuchs der stillen Authentifizierung möchten Sie möglicherweise auf eine alternative OTP-Methode zurückgreifen. 

Im Falle eines SIM-Wechsels sollten Sie möglicherweise auf eine OTP-Methode zurückgreifen, die nicht ausschließlich auf einem Mobilgerät basiert. Wenn eine SIM-Karte in betrügerischer Absicht ausgetauscht wurde, ist die stille Authentifizierung möglicherweise nicht mehr vertrauenswürdig. Ein SIM-Kartenwechsel ist nicht immer das Ergebnis einer Account-Übernahme, aber Vorsicht ist besser als Nachsicht – daher sollten Sie das OTP vielleicht an eine andere Adresse senden. 

In der start_email Funktion nutzen wir die Verify API, um einen Verifizierungsprozess per E-Mail zu starten:

def start_email(phone: str, email: str) -> dict:
    """
    Starts email OTP verification.
    Returns request_id.
    """
    request = VerifyRequest(
        brand="DemoApp",
        workflow=[EmailChannel(to=email)],
    )
    response = verify_client.verify.start_verification(request)
    return {"request_id": response.request_id}

Wenn die SIM-Karte nicht ausgetauscht wurde, der Mobilfunkanbieter des Endnutzers jedoch entweder nicht unterstützt wird oder die stille Authentifizierung fehlschlägt, greifen wir auf SMS-OTP zurück: 

def start_sms(phone: str) -> dict:
    """
    Starts SMS OTP verification.
    Returns channel and request_id.
    """
    logger.info(f"Starting SMS fallback with: {phone}")
    request = VerifyRequest(
        brand="DemoApp",
        workflow=[SmsChannel(to=phone)],
    )
    response = verify_client.verify.start_verification(request)
    return {"channel": "sms_otp", "request_id": response.request_id}

Überprüfung des OTP

Abschließend rufen wir den verify Endpunkt, wobei wir request_id und übermitteln dabei den Code, der entweder vom Endnutzer per E-Mail oder SMS als Einmalpasswort (OTP) bereitgestellt wurde oder auf der Client-Seite als Ergebnis der stillen Authentifizierung ermittelt wurde: 

def check_code(request_id: str, code: str) -> bool:
    """
    Validates OTP code with Vonage. Returns True if verified.
    """
    response = verify_client.verify.check_code(request_id, code)
    return {"verified": True, "status": response.status}

Der Backend-Server: Mit FastAPI alles zusammenführen

FastAPI ist ein leistungsstarkes Web-Framework zur Erstellung von HTTP-basierten Service-APIs in Python. Was FastAPI von anderen Python-Web-Frameworks unterscheidet, ist seine enge Anlehnung an Pydantic, einer Datenvalidierungsbibliothek für Python. Diese Kopplung ermöglicht es FastAPI, Daten zu validieren, zu serialisieren und zu deserialisieren. Dies bietet eine deklarativere Methode zur Festlegung der Struktur und der Datentypen für eingehende Anfragen wie HTTP-Body-Inhalte und ausgehende Antworten. FastAPI generiert zudem automatisch OpenAPI-Spezifikationen. All diese Funktionen zusammen machen es besonders geeignet für moderne REST-APIs, die Entwicklung von Microservices und Applications, die Echtzeitfunktionalität erfordern. 

Die Datei main.py enthält unsere FastAPI-Routen. 

In der Beispielanwendung greifen wir im Falle eines SIM-Wechsels auf ein per E-Mail versendetes Einmalpasswort (OTP) zurück. In einer produktionsreifen Anwendung wird diese E-Mail-Adresse vom Endbenutzer bei der Registrierung seines Accounts angegeben und in einer Datenbank gespeichert. In unserer minimalen Beispielanwendung geben Sie eine Test-E-Mail-Adresse an, die im Arbeitsspeicher gespeichert wird. Diese Speicherung im Arbeitsspeicher simuliert eine Datenbank mithilfe von Umgebungsvariablen, die Sie in der .env Datei angeben: 

USER_EMAIL_STORE = {os.environ["USER_PHONE_NUMBER"]: os.environ["USER_EMAIL"]}

Die /verification Route führt eine SIM-Swap-Prüfung durch und leitet je nach Status der SIM-Karte einen Verifizierungsworkflow zur stillen Authentifizierung ein. Wenn sim_swapped ist False die „Silent Authentication“ jedoch zu einem 412 (was bedeutet, dass das Netzwerk des Endnutzers nicht unterstützt wird), greifen wir auf SMS-OTP zurück: 

@app.post("/verification")
async def start_verification(req: VerificationRequest):
    """
    Starts the verification process:
    - Check if SIM is swapped-- if sim_swapped: True, fallback to email
    - If sim_swapped: False, begin Silent Authentication
    """
    phone = req.phone
    logger.info(f"Beginning authentication process for: {phone}")

    try:
        sim_swapped = check_sim_swap(phone)
        logger.info(f"Swap status for {phone}: {sim_swapped}")

        if sim_swapped or sim_swapped is None:
            logger.info("SIM swap flagged, stepping up to email")
            return {"channel": "email_stepup", "request_id": None}

        return start_silent_auth(phone)

    except Exception as e:
        raise HTTPException(status_code=500, detail=str(e))

@app.post("/fallback-sms")
async def fallback_sms(req: VerificationRequest):

    phone = req.phone
    # Uncomment the line below and comment out the line above
    # to test this app with a Virtual Operator number and receive an OTP
    # to a real phone number
    # phone = os.environ["USER_PHONE_NUMBER"]

    logger.info(f"SMS fallback requested, sending to: {phone}")
    try:
        return start_sms(phone)
    except Exception as e:
        raise HTTPException(status_code=500, detail=str(e))

Wenn sim_swapped ist True, geben wir {"channel": "email_stepup", "request_id": None} was den Client dazu veranlasst, die /send-email-otp: 

@app.post("/send-email-otp")
async def send_email_otp(req: VerificationRequest):
    """
    Starts the verification process via email:
    - Check if there is a stored email -- if no email, raise exception
    - If there is an email, begin verification
    """
    phone = req.phone

    logger.info(f"Stepping up to email for verification process for: {phone}")
    email = USER_EMAIL_STORE.get(phone)
    logger.info(f"Getting email address from simulated user database: {email}")

    if not email:
        raise HTTPException(status_code=404, detail="No email on file for this number")

    logger.info(f"Beginning email verification for: {email}")
    try:
        return start_email(phone, email)
    except Exception as e:
        raise HTTPException(status_code=500, detail=str(e))

Abschließend nutzen wir den /check-code Route, um den Authentifizierungsprozess abzuschließen: 

@app.post("/check-code")
async def verify_code(req: CheckCodeRequest):
    request_id = req.request_id
    code = req.code
    logger.info(f"Checking code for request_id: {request_id} with code: {code}")
    try:
        response = check_code(request_id, code)
        logger.info("Verification success!")
        return response
    except Exception as e:
        logger.info("Verification failure")
        return {"verified": False, "status": str(e)}

Verwendung des Vonage Android Client SDK zur Definition des Clients

Der Client für diese Beispielanwendung wurde mit Kotlin und nutzt moderne Bibliotheken wie OkHttp und Kotlin-Coroutinen sowie Jetpack Compose für die Benutzeroberfläche. Den vollständigen Code finden Sie im GitHub-Repository. Der Client bietet eine minimale mobile Benutzeroberfläche. 

Außerdem nutzt es das Vonage Android SDK, um den Teil der „Silent Authentication“ des Verifizierungsworkflows in der ApiClient.kt Datei: 

    suspend fun checkSilentAuth(url: String): String = withContext(Dispatchers.IO) {
        val params = VGCellularRequestParameters(
            url = url,
            headers = mapOf(),
            queryParameters = mapOf(),
            maxRedirectCount = 10
        )

        Log.d("DemoApp", "Attempting Silent Authentication ...")

        val response = VGCellularRequestClient.getInstance()
            .startCellularGetRequest(params, false)

        val sdkError = response.optString("error", "")
        if (sdkError.isNotEmpty()) {
            throw SilentAuthUnavailableException("SDK error: $sdkError")
        }

        val httpStatus = response.optInt("http_status", -1)
        if (httpStatus !in 200..299) {
            throw SilentAuthUnavailableException("HTTP $httpStatus")
        }

        val code = response.optJSONObject("response_body")?.optString("code", null)
        if (code.isNullOrBlank()) throw SilentAuthUnavailableException("Silent auth response missing 'code'")

        code
    }

Diese Zeile verwendet die Vonage-Android-Client-Bibliothek , um eine Mobilfunkverbindung zu erzwingen und eine GET Anfrage an die check_url , die von Vonage beim Start des Verifizierungsprozesses generiert wurde: 

val response = VGCellularRequestClient.getInstance()
    .startCellularGetRequest(params, false)

Wenn die GET Anfrage erfolgreich ist, wird ein Code zurückgegeben und zur Überprüfung an das Backend weitergeleitet. 

Umfassende Betrugsprävention

Befolgen Sie die Anweisungen in der README für den Code, um die Beispielanwendung zum Laufen zu bringen und sie auszuprobieren. Achten Sie darauf, die Network Registry Playground so zu konfigurieren, dass Sie sofort mit dem Testen der Netzwerkfunktionen beginnen können. Diese Beispielanwendung funktioniert am besten mit einem Live-Gerät, es gibt jedoch einige Einschränkungen zu beachten: Je nach Mobilfunkanbieter funktionieren die Identity Insights-API und der Verifizierungskanal für die stille Authentifizierung möglicherweise nicht. Lesen Sie die Vonage-Abdeckungsdokumentation , um zu prüfen, ob Ihr Anbieter unterstützt wird. Sie können auch den Vonage Virtual Operator nutzen, um verschiedene Szenarien zu testen.

Zusammenfassung

Betrug und Kontoübernahmen sind kostspielige Probleme – nicht nur in finanzieller Hinsicht, sondern auch im Hinblick auf das Vertrauen in die Marke und die Glaubwürdigkeit der Entwickler, deren Aufbau Jahre dauert. Obwohl herkömmliche SMS-OTPs weit verbreitet sind, weisen sie gut dokumentierte Schwachstellen auf: Mängel im SS7-Protokoll, SIM-Swap-Angriffe und Phishing untergraben ihre Zuverlässigkeit als eigenständiger zweiter Authentifizierungsfaktor. 

In diesem Blogbeitrag haben wir einen mehrschichtigen Ansatz zur Authentifizierung vorgestellt, der diese Schwachstellen direkt angeht: 

• Erkennung von SIM-Swap-Angriffen: Mithilfe der Vonage Number Insight API können Sie abfragen, ob eine Telefonnummer kürzlich einer neuen SIM-Karte zugewiesen wurde, und dieses Signal nutzen, um fundiertere Entscheidungen darüber zu treffen, wie Sie mit der Authentifizierung fortfahren. Eine kürzlich erfolgte Neuzuweisung ist ein Warnsignal, das den Wechsel zu einem vertrauenswürdigeren Verifizierungskanal rechtfertigt. 

• Stille Authentifizierung: Anstatt darauf zu vertrauen, dass ein Nutzer einen Code empfängt und eingibt, überprüft der stille Authentifizierungskanal der Vonage Verify API die Identität eines Geräts direkt über das Netz des Netzbetreibers. Kein Code, keine Benutzereingabe, keine Möglichkeit zum Abfangen. 

• Elegante Ausweichlösungen: Es gibt keine Methode, die in jedem Szenario funktioniert. Wenn die stille Authentifizierung von einem Netzbetreiber nicht unterstützt wird, greift die Anwendung auf SMS-OTP zurück. Wird ein SIM-Swap erkannt, wechselt die Anwendung zu E-Mail-OTP – einem Kanal, der nicht an das potenziell kompromittierte Gerät gebunden ist. 

Die Beispielanwendung veranschaulicht, wie diese drei Strategien mithilfe des Vonage Python SDK und des Vonage Android SDK zu einem einheitlichen, praxisnahen Authentifizierungsablauf kombiniert werden können. 

Betrug wird wahrscheinlich nie ganz ausgerottet werden können, aber mit den richtigen Tools und einem durchdachten, mehrschichtigen Ansatz können Sie es Angreifern erheblich erschweren, ihr Ziel zu erreichen – und es legitimen Nutzern erheblich erleichtern, Zugang zu erhalten. 

Weiterführende Literatur und Ressourcen

• Dokumentation zur Vonage Verify API: Die Verify API ist unser Produkt der nächsten Generation für die Zwei-Faktor-Authentifizierung (2FA).

• Dokumentation zur Vonage Identity Insights API: Die Number Insight API von Vonage liefert in Echtzeit Informationen zur Gültigkeit, Erreichbarkeit und zum Roaming-Status einer Telefonnummer und erklärt Ihnen, wie Sie die Nummer in Ihrer Application korrekt formatieren.

• Netzwerk-Registrierungs-Playground: Der Playground ermöglicht es Entwicklern, die Netzwerkfunktionen bereits zu nutzen, während sie auf die Genehmigung ihres Unternehmensprofils durch die Betreiber warten.

• Digitales Onboarding im Bankwesen mit „Silent Authentication“: Reduzieren Sie Reibungsverluste und Abbrüche beim digitalen Onboarding, indem Sie der „Silent Authentication“ der Verify API den Vorzug vor OTP geben.

Frage 1: Was ist eine „Silent Network Authentication“? 

Die „Silent Network Authentication“ (SNA) ist ein Verfahren auf Seiten des Netzbetreibers, bei dem die Telefonnummer eines Nutzers Verified wird, indem die mobile Datensitzung des Geräts über das Netz des Betreibers geleitet wird. Dabei wird kein Code an den Nutzer gesendet und es sind keine Eingaben erforderlich. Damit werden die Angriffsvektoren „SS7-Abhörung“ und „SIM-Swap“ geschlossen, die bei der SMS-OTP-Methode offen bleiben.  

Frage 2: Was ist der Unterschied zwischen der „Silent Network Authentication“ und der SIM-Swap-Erkennung? 

 Die „Silent Network Authentication“ Verifies, ob die derzeit in der mobilen Datensitzung aktive SIM-Karte mit derjenigen übereinstimmt, die der Netzbetreiber der zu überprüfenden Telefonnummer zugeordnet hat. Die SIM-Swap-Erkennung prüft, ob kürzlich eine neue SIM-Karte (physisch oder als eSIM) aktiviert und beim Netzbetreiber dieser Nummer zugeordnet wurde. Die Eigentumsverhältnisse an der Nummer selbst (Abrechnung, Vertrag, Account) ändern sich bei einem SIM-Swap nicht; der Angreifer erlangt Zugriff auf die Netzwerk-Routing-Ebene, nicht jedoch das rechtliche Eigentumsrecht. Die SNA bestätigt, dass die aktuelle Verknüpfung zwischen SIM-Karte und Nummer unverändert ist, und die SIM-Swap-Erkennung kennzeichnet, ob diese Verknüpfung kürzlich aktualisiert wurde. Durch die Kombination beider Prüfungen im selben Anmeldeablauf werden Angreifer abgefangen, die einen Mobilfunkanbieter bereits davon überzeugt haben, ihnen eine SIM-Karte auszustellen, die der Nummer des Opfers zugeordnet ist, bevor sie einen Anmeldevorgang auslösen. 

Frage 3: Funktioniert die „Silent“-Netzwerkauthentifizierung über WLAN? 

Nein. Für die „Silent Network“-Authentifizierung ist eine aktive mobile Datenverbindung erforderlich, da der CAMARA-Datenfluss über das Netz des Mobilfunkanbieters und nicht über das Internet geleitet wird. Geräte, die ausschließlich über WLAN verbunden sind, Tablets ohne SIM-Karte und Desktop-Computer können die Umleitung über mobile Daten nicht durchführen. Sie müssen eine Ausweichlösung implementieren – die Vonage Verify API mit SMS oder Voice-OTP ist die Standard-Ausweichlösung und kann über denselben Vonage Python SDK-Client ausgelöst werden. 

Frage 4: Welche Python-Bibliotheken benötige ich für die automatische Netzwerkauthentifizierung mit Vonage? 

Sie benötigen Vonage (das Vonage-Python-SDK auf PyPI), fastapi, uvicorn und python-dotenv. Für den Produktivbetrieb fügen Sie redis-py hinzu, um auth_request_ids zwischen der Initiierungs- und der Callback-Route zu speichern, sowie slowapi oder eine benutzerdefinierte Middleware zur Ratenbegrenzung des Authentifizierungs-Endpunkts.