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 früheren Lösungsansätze, von Einmalcodes bis hin zu „Magic Links“, haben dieses Geheimnis lediglich an einen besser geschützten Ort verlagert. Wenn Sie einen umfassenden Überblick über diese Geschichte sowie über die beiden Verfahren erhalten möchten, die ein Passkey funktionsfähig machen, finden Sie meine Ausführungen dazu 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 Stärken lassen Passkeys jedoch zwei Türen ungesichert. Sie können Ihnen nicht sagen, 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 sind genau dort, wo  Vonage Silent Authentication  glänzt: Sie Verifies 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 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 entscheiden muss, ob eine Anmeldeseite echt ist. 

Stille Authentifizierung verifiziert 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 Mobilfunkanbieter überprüft direkt anhand seiner eigenen Daten, ob 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 Passkeys 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, obwohl der Nachweis dafür nicht mehr vorhanden ist?“ 

Passkeys bieten eine hervorragende Lösung für das Anmeldeproblem, 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. 

The Day One Problem

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. 

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. 

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

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

4. 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. 

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

Voraussetzungen

• 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. 

• A  Vonage-API-Account

Schritt 1: Verify the number during registration in the background

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" 
} 

Geben Sie das check_url an den Client weiter und lassen Sie das Gerät diese über seine Mobilfunkverbindung öffnen. Dies ist die einzige zwingende Voraussetzung für „Silent Auth“: Wenn die Anfrage über WLAN gesendet wird, sieht der Netzbetreiber 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 wandeln gewöhnliche Anmeldedaten in einen Passkey um. Diese Einstellungen erfordern einen auffindbare Anmeldeinformation (resident_key: "required"), damit die Anmeldung ohne Benutzernamen erfolgen kann, und erfordern eine eine Benutzerüberprüfung 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 sonst ein manipulierter Client die biometrische Geste überspringen und Ihre Multi-Faktor-Anmeldung unbemerkt auf einen einzigen Faktor herabstufen kann. Nachdem dies Verified wurde, vergleichen Sie die Antwort mit der von Ihnen ausgegebenen Herausforderung, 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 gar nicht erst aufgerufen. Der Nutzer tippt auf eine Schaltfläche, der Browser zeigt die Account-Auswahl an, mit einer einzigen Geste wird die Anfrage des Servers bestätigt – und schon ist alles erledigt. 

An dieser Stelle fragen Sie sich vielleicht: Warum sollte man „Silent Auth“ nicht auch bei jeder Anmeldung als zusätzliche Sicherheitsebene einsetzen? Die Antwort lautet: Weil Sie dann für eine Abdeckung bezahlen würden, die Sie nicht benötigen, und gleichzeitig eine Abdeckung verlieren würden, die Sie tatsächlich benötigen. Eine Passkey-Anmeldung belegt bereits den Besitz eines registrierten Geräts sowie eine aktuelle biometrische Authentifizierung und funktioniert auf Desktops, über WLAN und sogar in einem Keller ohne Empfang – genau an den Orten, die eine Mobilfunkanbieter-Prüfung nicht erreichen kann. Jede „Silent Auth“-Prüfung kostet zudem einen Netzwerk-Roundtrip (sowie eine Gebühr pro Prüfung). Das ist für gelegentliche Lebenszyklus-Ereignisse in Ordnung, macht sich jedoch bei jeder Anmeldung als zusätzliche Belastung bemerkbar. Mit anderen Worten: Sparen Sie sich die Netzbetreiberprüfung für die Momente auf, in denen der Passkey nicht „sprechen“ kann. 

Schritt 4: Genesung: Dieselbe 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. 

Es lohnt sich, ehrlich über den Kompromiss zu sprechen, da es bei der Nutzerverifizierung keine Allheilmittel gibt. Eine an eine Telefonnummer gebundene Wiederherstellung unterliegt dem Lebenszyklus der Telefonnummer. Numbers werden wiederverwendet, und es gibt Betrugsfälle durch SIM-Swapping. Deshalb stellt die Überprüfung der betreibereigenen Aufzeichnungen auf kürzlich erfolgte SIM-Wechsel durch „Silent Auth“ eine deutlich höhere Sicherheitsbarriere 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: 

Jedes Authentifizierungssystem hat ein Bootstrap-Problem und ein Wiederherstellungsproblem, und die meisten Lösungen weichen genau in diesen beiden Momenten stillschweigend auf einen für Phishing anfälligen Kanal zurück. Durch die Kombination von Passkeys mit „Silent Authentication“ bleibt der gesamte Lebenszyklus auf Faktoren beschränkt, bei denen dem Nutzer niemals ein Geheimnis angezeigt wird. Der Browser überprüft die Herkunft, der Mobilfunkanbieter überprüft die SIM-Karte, und der Nutzer wird niemals aufgefordert, etwas zu beurteilen, was ein Phisher vortäuschen könnte – was bedeutet, dass es niemals ein Geheimnis gibt, das dem Nutzer ausredet werden könnte. 

Und genau das ist die Konstellation, die der Titel versprochen hat: „Silent Auth“ ist der stille Teilhaber. Er richtet den Trust ein, der das Unternehmen auf den Weg bringt, greift wieder ein, wenn das Unternehmen gerettet werden muss, und bleibt den Rest der Zeit unsichtbar, während der Passkey das Tagesgeschäft leitet. 

Schlussfolgerung

Wenn Sie sich näher mit einer der beiden Hälften befassen möchten, finden Sie im  Leitfaden zur stillen Authentifizierung  behandelt die Abdeckung und die Registrierung in der Netzwerkregistrierung, das  Tutorial „Erste Schritte mit der stillen Authentifizierung“  führt durch den check_url den gesamten Ablauf mit einem Node.js-Backend Schritt für Schritt durch, und der  Beitrag zu Best Practices befasst sich eingehend mit der Gestaltung von Fallback-Workflows. 

Haben Sie Passkeys bereits mit der netzwerkbasierten Authentifizierung kombiniert oder planen Sie dies? Wir würden uns sehr freuen, zu erfahren, wie es damit läuft.