Jeder Passkey braucht einen stillen Partner

Passkeys verbessern die Sicherheit bei der Authentifizierung erheblich, lösen jedoch nicht jedes Identitätsproblem. In diesem Tutorial erfahren Sie, warum die Registrierung und die Wiederherstellung des Accounts nach wie vor schwierig sind, wie „Silent Authentication“ diese Lücken schließt und wie Sie den gesamten Ablauf mithilfe der Vonage Verify API umsetzen können. 

Passwörter sind der älteste, noch nicht behobene Fehler in Software, und Passkeys sind die erste Lösung, die das gemeinsame Geheimnis beseitigt, anstatt es nur an einen anderen Ort zu verlagern. Alle bisherigen Lösungen, von Einmalcodes bis hin zu „Magic Links“, haben dieses Geheimnis lediglich an einen besser geschützten Ort verlagert. IchiWenn Sie einen umfassenden Überblick über diese Geschichte und über die beiden Verfahren erhalten möchten, die einen Passkey zum Funktionieren bringen, habe ich dies in „Passkeys from first principles“aufgeschrieben. 

Passkeys setzen sich zunehmend durch. Indem sie das Passwort durch ein Paar aus öffentlichem und privatem Schlüssel ersetzen – wobei der private Schlüssel das Gerät des Nutzers niemals verlässt und der Server nur den öffentlichen Schlüssel speichert –, machen sie Phishing von vornherein unwirksam. Der Browser weigert sich schlichtweg, den Schlüssel auf einer falschen Website zu verwenden, und eine gestohlene Anmeldedaten-Datenbank wird zu einer Liste wertloser öffentlicher Schlüssel. 

Trotz all dieser Vorteile lassen Passkeys jedoch immer noch zwei Türen ungeschützt. Sie können nicht erkennen, wer vor der Tür steht, wenn sich jemand zum ersten Mal anmeldet, und sie können einen berechtigten Nutzer nicht wieder hereinlassen, wenn dessen letzter Passkey verloren gegangen ist. Beide Türen befinden sich genau dort, wo Vonage Silent Authentication glänzt: Sie Verifyt den Besitz einer Telefonnummer mithilfe der SIM-Karte und des Netzbetreibernetzes – ohne Codes, die eingegeben werden müssen, und ohne dass ein Phisher etwas abfangen kann. 

Zwei phishingresistente, reibungslose Faktoren, die jeweils den toten Winkel des anderen abdecken. Schauen wir uns zunächst an, warum sie so gut zusammenpassen, und erstellen wir dann den Ablauf mit der Verify v2-APIaufbauen. 

So funktionieren Passkeys und WebAuthn 

Passkeys sind WebAuthn-Anmeldedaten. Bei der Registrierung generiert das Gerät ein Schlüsselpaar in sicherer Hardware und sendet den öffentlichen Schlüssel an den Server. Bei der Anmeldung stellt der Server eine zufällige Herausforderung aus, das Gerät signiert diese nach einer biometrischen Geste oder der Eingabe einer PIN, und der Server Verifies die Signatur. Ein Daumendruck ist bereits eine Multi-Faktor-Authentifizierung: etwas, das man besitzt (das Gerät), plus etwas, das man ist (die Geste). Entscheidend ist, dass der Browser einen Passkey nur auf der Domain anbietet, für die er erstellt wurde, sodass nicht mehr der Nutzer selbst entscheiden muss, ob eine Anmeldeseite echt ist. 

Stille Authentifizierung überprüft einen Nutzer anhand seiner SIM-Karte. Ihr Backend startet eine Überprüfung über die Verify v2-API, erhält eine „check_url“, und das Gerät des Nutzers öffnet diese URL über seine Mobilfunkverbindung. Der Netzbetreiber bestätigt , direkt anhand seiner eigenen Daten , , dass die Anfrage von dem Gerät stammt, das Inhaber dieser Telefonnummer ist, und gibt eine verifizierte GSM-Antwort zurück. Es wird keine SMS versendet, kein sechsstelliger Code eingegeben, und auf dem Bildschirm erscheint nichts, was ein Angreifer durch Social Engineering vom Nutzer ergaunern könnte. Die Authentifizierung erfolgt direkt zwischen dem Mobilfunkanbieter und dem Mobilgerät, wodurch das klassische OTP-Phishing-Szenario vollständig ausgeschlossen wird. 

Beachten Sie die Symmetrie: 

• Ein Passkey dient als Nachweis dafür, dass Sie im Besitz eines privaten Schlüssels sind, der an Ihren Dienst gebunden ist. 

• „Silent Auth“ bestätigt den Besitz einer SIM-Karte, die an eine Telefonnummer gebunden ist. 

Keiner der beiden Faktoren zeigt dem Benutzer jemals ein Geheimnis an, sodass keiner der beiden dem Benutzer ein Geheimnis liefert, das er preisgeben könnte. 

Wenn Passwörter einen Freund brauchen 

Man sollte sich vor Augen halten, dass Registrierung, Anmeldung und Passwortwiederherstellung nicht dieselbe Frage sind, die dreimal gestellt wird. Bei der Registrierung wird gefragt: „Wer ist das?“, beim Einloggen: „Ist das dieselbe Person, die sich registriert hat?“ und bei der Passwortwiederherstellung: „Ist das wirklich diese Person, jetzt, wo der Nachweis dafür weg ist?“. Passkeys bieten eine hervorragende Antwort auf die Frage zur Anmeldung, geben jedoch keinerlei Antwort auf die beiden anderen Fragen. 

Das „Day-One“-Problem 

Ein Passkey kann lediglich nachweisen, dass die Person, die sich anmeldet, auch diejenige ist, die sich registriert hat. Er sagt nichts darüber aus, wer sich registriert hat. Am ersten Tag gibt es noch keinen Passkey, sodass die meisten passwortlosen Registrierungen auf das schwächste Glied im gesamten System zurückgreifen: eine E-Mail-Adresse, die entweder nicht verifiziert ist oder über einen Link verifiziert wurde, der selbst für Phishing-Angriffe anfällig ist. Wenn ein Angreifer den Account für victim@example.com noch vor dem Opfer erstellt und ihn mit seinem eigenen Passkey verknüpft, haben Sie bereits ein Problem, das noch vor der Kontoübernahme auftritt, noch bevor Ihr Nutzer überhaupt in Erscheinung getreten ist. 

Die Verknüpfung der Registrierung mit einer stillschweigend verifizierten Telefonnummer verändert die Situation. Der Account wird anhand einer Nummer angelegt, für die der Netzbetreiber gerade bestätigt hat, dass sie auf diesem Gerät aktiv ist, und erst dann wird der Passkey-Vorgang durchgeführt. Der Passkey erweitert nun kryptografisch eine Identität, die Sie tatsächlich verifiziert haben, und nicht eine, die der Nutzer lediglich eingegeben hat. 

[TODO: Bild]

Das Problem des letzten Geräts 

Der zweite Weg ist die Wiederherstellung. Ein Nutzer mit einem gerätegebundenen Passkey ist nur ein verlorenes Smartphone davon entfernt, ausgesperrt zu werden, und selbst bei synchronisierten Passkeys wird davon ausgegangen, dass der Nutzer weiterhin Zugriff auf seinen Plattform-Account hat. Die meisten Produkte greifen auf einen per E-Mail versendeten „Magic Link“ zurück, der still und leise alles wieder einführt, was durch Passkeys abgeschafft wurde: ein Bearer-Token, das im Posteingang liegt und durch ein Passwort geschützt ist. 

„Silent Auth“ bietet Ihnen einen Wiederherstellungsweg mit demselben Sicherheitsniveau wie das Gerät, das wiederhergestellt wird. Neues Handy, gleiche Nummer: Der Mobilfunkanbieter garantiert für die SIM-Karte, der Nutzer registriert einen Passkey neu, und zu keinem Zeitpunkt wird ein Code über einen Kanal übertragen, den ein Angreifer abfangen könnte. 

[TODO: Bild]
Der kombinierte Durchfluss 

Hier ist der gesamte Lebenszyklus: 

1. Registrierung: Verify the phone number with Silent Auth, create the account, and then register the first passkey. 

1. Jede weitere Anmeldung: Nur mit Passkey. Eine Geste, kein Datenaustausch mit einem Mobilfunkanbieter, funktioniert auf jedem Gerät, einschließlich Desktop-Computern. 

1. Wiederherstellung oder ein neues Gerät ohne Synchronisierung: Erneut „Silent Auth“ durchführen und anschließend einen Ersatz-Passkey registrieren. 

1. Optionaler zusätzlicher Schritt: Bei risikoreichen Aktionen (Auszahlung, E-Mail-Änderung, Hinzufügen eines neuen Passworts über einen unbekannten Browser) sollte im Hintergrund eine „Silent Auth“-Prüfung als zweiter, unabhängiger Faktor durchgeführt werden. 

[TODO: Bild]

Passkeys kümmern sich um den Alltag; Silent Auth übernimmt die Sonderfälle. Schreiben wir nun die interessanten Teile. 

Voraussetzungen 

• A Vonage-API-Account. Falls Sie noch keines haben, können Sie sich <sign-up></sign-up> noch heute registrieren und mit kostenlosem Guthaben loslegen. 

• Ihre Anwendung wurde im Netzwerkregister für den Produktiveinsatz registriert (während der Entwicklungsphase steht Ihnen die Sandbox zur Verfügung – mehr dazu weiter unten). 

• Ein Backend, das eine Sitzung aufrechterhalten kann; die folgenden Codeausschnitte verwenden reines Curl und Browser-JavaScript, sodass Sie sie auf die Plattform Ihrer Wahl übertragen können. 

• Ein Smartphone mit SIM-Karte und Mobilfunkdaten zum Testen der „Silent Auth“-Phase. 

Schritt 1: Verify die Nummer bei der Anmeldung im Hintergrund 

Wenn ein neuer Nutzer seine Telefonnummer angibt, leitet Ihr Backend eine Verifizierung ein. Das „workflow“-Array ist der Kern des Ganzen: Zunächst „silent_auth“, mit einem SMS-Fallback für die Fälle, in denen „Silent Auth“ nicht ausgeführt werden kann. 

 

curl -X POST https://api.nexmo.com/v2/verify \ 

  -H "Authorization: Bearer $JWT" \ 

  -H "Content-Type: application/json" \ 

  -d '{ 

    "brand": "ACME Inc", 

    "workflow": [ 

      { "channel": "silent_auth", "to": "447700900000" }, 

      { "channel": "sms", "to": "447700900000" } 

    ] 

  }' 

Die Antwort enthält ein request_id und bei der stillen Authentifizierung ein check_url: 

{ 

  "request_id": "b3a2f4d0-1234-4d6e-9f00-example00000", 

  "check_url": "https://api-eu-3.vonage.com/v2/verify/b3a2f4d0.../silent-auth/redirect" 

} 

Übergeben Sie die check_url an den Kunden weiter und lassen Sie das Gerät die Datei über seine Mobilfunkverbindung. Dies ist die einzige zwingende Voraussetzung für „Silent Auth“: Wenn die Anfrage über WLAN gesendet wird, sieht der Mobilfunkanbieter sie nicht und die Überprüfung schlägt fehl. Die Vonage-Client-Bibliotheken für iOS und Android dienen genau dazu, die Anfrage über mobile Daten zu leiten, selbst wenn eine WLAN-Verbindung besteht. Verwenden Sie daher diese Bibliotheken, anstatt eine eigene Lösung zu entwickeln. 

Das Gerät durchläuft eine kurze Kette von Weiterleitungen in das Netzwerk des Netzbetreibers und sendet anschließend einen Code zurück, den Ihr Client an Ihr Backend übermittelt und Ihr Backend an Verify weiterleitet: 

curl -X POST https://api.nexmo.com/v2/verify/$REQUEST_ID \ 

  -H "Authorization: Bearer $JWT" \ 

  -H "Content-Type: application/json" \ 

  -d '{ "code": "'$CODE'" }' 

Ein "status": "completed" bedeutet, dass der Mobilfunkanbieter für die SIM-Karte gebürgt hat. Der Nutzer wurde Verified, und hier kommt der Teil, den man genießen sollte: , er hat davon überhaupt nichts mitbekommen. Es kam kein Code an, es wurde nichts eingegeben. Aus seiner Sicht, hat er eine Telefonnummer eingegeben und wurde automatisch angemeldet. 

Fügen Sie während der Entwicklung "sandbox": true dem Workflow-Eintrag hinzu und nutzen Sie den Network Registry Playground, damit Sie den gesamten Ablauf auch ohne Netzabdeckung testen können. 

Schritt 2: Registrieren Sie den ersten Passkey 

Erst jetzt, und nur jetzt, sollten Sie den Account erstellen und sofort die WebAuthn-Registrierung durchführen. Die native API des Browsers benötigt heutzutage keine Abhängigkeiten mehr: 

// The server generated these options, including a random challenge 

// and the user object: { id: userHandle, name: phoneOrEmail } 

const options = PublicKeyCredential.parseCreationOptionsFromJSON(optionsJSON); 

 

// The OS prompts for Touch ID / Face ID / Windows Hello and mints 

// the key pair inside secure hardware. The private key never leaves. 

const credential = await navigator.credentials.create({ publicKey: options }); 

 

await fetch("/registration", { 

  method: "POST", 

  headers: { "Content-Type": "application/json" }, 

  body: JSON.stringify({ credential: credential.toJSON() }), 

}); 

Zwei serverseitige Einstellungen verwandeln gewöhnliche Anmeldedaten in einen Passkey. Diese Einstellungen: fordern eine auffindbare Anmeldeinformation (resident_key: „required“), damit die Anmeldung ohne Benutzernamen erfolgen kann, und erfordern eine Benutzerauthentifizierung für die biometrische Geste. Beachten Sie, dass die Option „user_verification“ lediglich die Geste vom Browser anfordert; es ist Ihr Verifizierungsschritt auf dem Server, der auch das Flag „user-verified“ in der Antwort des Authentifikators überprüfen muss, da andernfalls ein manipulierter Client die biometrische Geste überspringen und Ihre Multi-Faktor-Anmeldung unbemerkt auf einen einzigen Faktor herabstufen könnte. Nachdem Sie dies Verify haben, vergleichen Sie die Antwort mit der von Ihnen ausgegebenen Challenge, speichern Sie den öffentlichen Schlüssel, und der Account verfügt nun über eine phishing-resistente Anmeldeinformation, die an eine vom Mobilfunkanbieter verifizierte Telefonnummer gebunden ist. 

Ein Hinweis zum Design: Die von Ihnen verifizierte Telefonnummer eignet sich hervorragend als für Menschen lesbare Bezeichnung für den Passkey (user.name in den Erstellungsoptionen), und die WebAuthn-Spezifikation führt Telefonnummern neben E-Mail-Adressen und Benutzernamen ausdrücklich für genau diesen Zweck auf. Verwenden Sie sie jedoch niemals als Benutzer-ID (user.id); diese muss ein undurchsichtiger, zufälliger Bezeichner bleiben. 

Schritt 3: Melden Sie sich ausschließlich mit dem Passkey an 

Bei der alltäglichen Anmeldung wird die Verify API nie aufgerufen. Der Nutzer tippt auf eine Schaltfläche, der Browser zeigt die Account-Auswahl an, mit einer einzigen Geste wird die Herausforderung des Servers signiert, und schon fertig. 

An dieser Stelle fragen Sie sich vielleicht: Warum sollte man „Silent Auth“ nicht auch bei jeder Anmeldung als zusätzliche Sicherheitsstufe einsetzen? Die Antwort lautet bB, weil dann würdest du für eine Absicherung bezahlen, die du nicht brauchst, und gleichzeitig die Absicherung verlieren, die du brauchst. Eine Anmeldung per Passkey belegt bereits den Besitz eines registrierten Geräts sowie eine aktuelle biometrische Authentifizierung, und sie funktioniert auf Desktops, über WLAN und sogar in einem Keller ohne Empfang– und das sind -- genau die Orte sind, die eine Überprüfung durch den Mobilfunkanbieter nicht erreichen kann. Jede „Silent Auth“-Überprüfung kostet zudem einen Netzwerk-Roundtrip (sowie eine Gebühr pro Überprüfung). Das ist für gelegentliche Ereignisse im Lebenszyklus in Ordnung, aber als Belastung bei jeder Anmeldung spürbar. Mit anderen Worten: sShebe dir den Träger für die Momente auf, in denen der Passkey nicht sprechen kann. 

Schritt 4: Wiederherstellung: , Ttdie gleiche Tür wie am ersten Tag 

Wenn ein Benutzer seinen letzten Passkey verliert, besteht die Wiederherstellung lediglich aus Schritt 1, gefolgt von erneutem Schritt 2: Die bei der Registrierung angegebene Nummer wird im Hintergrund Verify, eine kurzlebige Wiederherstellungssitzung wird eröffnet und der Benutzer kann einen neuen Passkey generieren. Der Arbeitsablauf mit dem SMS-Fallback berücksichtigt bereits die kniffligen Fälle, wie zum Beispiel den Nutzer, dessen neues Handy zwar eine SIM-Karte hat, der sich aber gerade an einem Desktop-Computer befindet – in diesem Fall leitet „Verify“ den Arbeitsablauf einfach zum nächsten Kanal weiter. 

Man sollte sich über diesen Kompromiss im Klaren sein, denn wenn es um die Nutzerüberprüfung geht, gibt es keine Allzwecklösung. : RrEine an eine Telefonnummer gebundene Wiederherstellung unterliegt dem Lebenszyklus dieser Telefonnummer. Nummern werden wiederverwendet, und es gibt Betrugsfälle durch SIM-Swapping. Deshalb stellt die Überprüfung durch „Silent Auth“ anhand der betreibereigenen Aufzeichnungen auf kürzlich erfolgte SIM-Wechsel eine deutlich höhere Sicherheitsschwelle dar als ein SMS-Code, und deshalb sollten Sie die Wiederherstellung als günstigen Zeitpunkt für eine besonders gründliche Überprüfung nutzen (benachrichtigen Sie alle anderen Kanäle, die Ihnen zur Verfügung stehen, verzögern Sie hochriskante Aktionen und protokollieren Sie das Ereignis). 

Warum diese Kombination funktioniert 

Wenn man einen Schritt zurücktritt, bietet sich ein angenehm übersichtliches Bild: