Passkey-Fallback & Recovery: Der Identifier-First-Ansatz

1. Einführung#

Passkeys haben sich zu einer echten Alternative zu traditionellen Authentifizierungsmethoden entwickelt, wobei fast 95 % der Geräte bereit für Passkeys sind. Selbst die fortschrittlichsten Systeme benötigen jedoch effektive Fallback- und Recovery-Strategien, um Szenarien zu bewältigen, in denen Passkeys nicht zugänglich (Fallback) oder gar verloren gegangen sind (Recovery). Dieser Leitfaden zielt darauf ab, die verschiedenen Szenarien zu untersuchen, in denen Fallbacks und Recoveries erforderlich sind, und zu diskutieren, wie mögliche Lösungen aussehen können.

Wenn man über Fallback- und Recovery-Methoden nachdenkt, ist es wichtig, dass deren Sicherheitsniveau dem der primären Authentifizierungsmethode entspricht. Dieser Leitfaden unterscheidet zwischen verschiedenen Nutzungsmöglichkeiten von Passkeys und konzentriert sich insbesondere auf Kontexte, in denen Passkeys als eigenständige MFA verwendet werden, um Fallback- und Recovery-Methoden entsprechend anzupassen.

Schlüsselfragen:

• Welche Fallback-Szenarien existieren? Was sind die potenziellen Fallback-Szenarien, die bei Passkey-Systemen auftreten können, und wie sollten sie gehandhabt werden, um die Sicherheit aufrechtzuerhalten?
• Wie sollte das Recovery gehandhabt werden? Wie sollten, abhängig von den Nutzungsmustern von Passkeys, insbesondere in Umgebungen, die MFA verwenden, Recovery-Prozesse gestaltet werden, um sicherzustellen, dass sie sicher sind?

Durch die Untersuchung dieser Fragen wird dieser Leitfaden Produktmanagern und Entwicklern die notwendigen Einblicke geben, um Passkey-Systeme effektiv zu entwerfen, zu implementieren und zu verwalten, und sicherzustellen, dass die Sicherheit nicht auf Kosten der Benutzererfahrung (UX) geht.

2. Definitionen: Identifier, Sicherheitsstufe & Fallback & Recovery#

Bevor wir in Fallback- und Recovery-Strategien eintauchen, ist es wichtig, ein klares Verständnis einiger grundlegender Begriffe zu etablieren, die wir verwenden werden.

2.1 Identifier: E-Mail, Telefonnummer und Benutzername#

In den meisten Geschäfts- und Verbrauchersystemen beruht die Authentifizierung auf drei primären Identifikatoren (Identifiern): E-Mail, Telefonnummer und Benutzername.

Die überwiegende Mehrheit der Systeme verwendet E-Mail als primären Identifier, insbesondere in webbasierten Anwendungen. Mobile-First- oder App-First-Plattformen bevorzugen jedoch oft die Verwendung der Telefonnummer als Identifier, da sich ein SMS-basiertes OTP (One-Time Passcode) leicht vorab ausfüllen und automatisch einfügen lässt. In einigen Fällen müssen Benutzer neben diesen Identifiern auch einen Benutzernamen einrichten, hauptsächlich für Plattformen, die einen eindeutigen Anzeigenamen erfordern. Es gibt auch einen wachsenden Trend, insbesondere auf größeren Plattformen, die Verwendung von sowohl E-Mail als auch Telefonnummer für zusätzliche Flexibilität zuzulassen.

Während der anfänglichen Registrierung werden diese Identifier typischerweise entweder über einen Bestätigungslink / OTP (für E-Mail) oder ein OTP (für Telefonnummer) verifiziert, um sicherzustellen, dass der Identifier der richtigen Person gehört. Im Falle eines Zugriffsverlusts ist der Nachweis der Kontrolle über die zuvor verifizierte E-Mail oder Telefonnummer in der Regel ausreichend, um den Kontozugriff wiederherzustellen. Da diese Identifier die zuverlässigsten Formen der Kommunikation mit Benutzern sind, werden Telefonnummern oft für MFA-Zwecke (Multi-Faktor-Authentifizierung) erfasst, wobei SMS ein häufig verwendeter zweiter Faktor ist.

Benutzernamen werden oft eingesetzt, um eine zusätzliche Ebene der Benutzeridentität in Systemen bereitzustellen, in denen nach außen sichtbare Identifier erforderlich sind, wie z. B. in sozialen Medien, Foren oder bestimmten professionellen Plattformen. Obwohl sie bei der Authentifizierung nicht dieselbe funktionale Rolle wie E-Mail oder Telefonnummern spielen, bieten Benutzernamen den Benutzern eine erkennbare Identität in öffentlichen oder Peer-to-Peer-Kontexten. Sie führen jedoch zu zusätzlicher Komplexität, da Benutzer sie oft vergessen können, und in den meisten Fällen ist ein weiterer Identifier neben dem Benutzernamen erforderlich. Daher werden wir uns in diesem Artikel nicht auf Benutzernamen konzentrieren.

Andere 2FA-Optionen, wie Authenticator-Apps (die TOTP-Codes generieren), sind nicht auf einen Identifier angewiesen, aber oft komplexer für einen durchschnittlichen Benutzer einzurichten. Passkeys haben auch die Möglichkeit eingeführt, ohne einen Identifier zu arbeiten (benutzernamenlose Authentifizierung), eine Funktion, die im Krypto-Bereich zunehmend beliebter wird. Für Verbraucher- und Geschäftslösungen macht jedoch die Notwendigkeit, mit Benutzern (oft per E-Mail) für Fallback- oder Recovery-Zwecke zu kommunizieren, benutzernamenlose Systeme unpraktisch.

2.2 Sicherheitsstufe: Single-Factor-Authentication (SFA) & Multi-Factor-Authentication (MFA)#

Single Factor Authentication (SFA)-Systeme sind solche, die auf einer Form der Authentifizierung beruhen, um die Identität des Benutzers zu überprüfen. Meistens ist dieser einzige Faktor ein Passwort, aber es kann sich auch um einen Social Login, ein E-Mail-OTP oder eine andere Methode handeln, die nur eine Art von Nachweis erfordert. Die meisten Systeme im heutigen Web sind SFA-Systeme. Es gibt jedoch einen bekannten Kompromiss bei der Sicherheit. Wenn Passkeys integriert werden, dienen diese typischerweise entweder als Ergänzung oder als Ersatz für herkömmliche Passwörter und erhöhen so den Komfort des Systems. Es ist üblich, dass solche Systeme weiterhin Fallback-Optionen wie E-Mail-OTPs oder Social Logins zulassen, was die Benutzererfahrung durch Reduzierung von Passwörtern verbessert, aber die Sicherheit des Systems nicht über SFA hinaus erhöht.

Multi-Factor Authentication (MFA) umfasst zwei oder mehr unabhängige Faktoren zur Überprüfung der Identität eines Benutzers; dies macht es sicherer als SFA. Diese Faktoren können etwas umfassen, das der Benutzer weiß (Passwort oder PIN), etwas, das der Benutzer hat (ein Sicherheitstoken oder eine Handy-App), und etwas, das der Benutzer ist (biometrische Verifizierung wie Fingerabdrücke oder Gesichtserkennung). MFA-Systeme sind darauf ausgelegt, vor spezifischen Schwachstellen zu schützen, gegen die SFA-Systeme sich nicht wehren können, wie etwa Phishing-Angriffe oder Passwortdiebstähle. Wenn Passkeys innerhalb eines MFA-Systems verwendet werden, werden sie im Allgemeinen als eigenständige MFA-Option eingesetzt. In diesen Fällen ist es entscheidend, dass alle Fallback- oder Recovery-Methoden das gleiche Sicherheitsniveau wie Passkeys aufrechterhalten.

2.3 Fallback & Recovery#

Fallbacks werden in allen Systemen verwendet, in denen mehrere Authentifizierungsmethoden nebeneinander existieren. Sie werden eingesetzt, wenn die primären Methoden nicht verfügbar sind – oft hat der Benutzer zu Beginn die Wahl, wie er sich registrieren möchte (z. B. Social Login vs. Passwort). Ein Fallback könnte alternative Authentifizierungsstrategien wie OTPs per E-Mail, Passwörter, Social Logins mit übereinstimmenden E-Mails, native App-Pushes, QR-Codes oder Sicherheitsschlüssel (Security Keys) umfassen. Jede dieser Fallback-Methoden variiert in ihrer Sicherheitsqualität, und die Auswahl der geeigneten Fallback-Option ist entscheidend für die Abwägung von Benutzerkomfort und Sicherheitsanforderungen.

In Umgebungen, die Passkeys als Teil eines Multi-Faktor-Authentifizierungssystems (MFA) nutzen, müssen diese Fallback-Methoden sorgfältig bedacht werden, um sicherzustellen, dass sie eine mit Passkeys vergleichbare Multi-Faktor-Sicherheit bieten. Recovery-Prozesse (Wiederherstellung) werden wichtig, wenn Benutzer den Zugriff auf alle etablierten Authentifizierungsmaßnahmen verlieren, die den erforderlichen Sicherheitsstandards (SFA oder MFA) entsprechen. Dies ist weniger kritisch in Single-Factor-Systemen, wo möglicherweise mehrere Recovery-Optionen verfügbar sind, wie das Zurücksetzen eines Passworts über ein E-Mail-OTP, was die Kontrolle des Benutzers über einen verknüpften Identifier effektiv validiert. Allerdings ist das Recovery in 2FA/MFA-Systemen besonders herausfordernd, da diese Systeme zur Überprüfung inhärent auf mehrere Faktoren angewiesen sind. In Szenarien, in denen ein Benutzer das mobile Betriebssystem wechselt – z. B. vom iPhone zum Android-Telefon – und die verknüpften Passkeys sowie die Telefonnummer verliert, können die verbleibenden Faktoren (z. B. nur ein Passwort) die 2FA-Anforderungen nicht erfüllen. Ein Recovery in diesen Fällen kann die Erstellung neuer Identitätsnachweise erfordern, was manuelle Supportanfragen oder innovativere Lösungen beinhalten kann, auf die wir später eingehen werden.

3. Passkey Login Fallback: Manueller Passkey-Login vs. Automatischer Passkey-Login#

Bei der Implementierung einer Passkey-Lösung ist eine der ersten Entscheidungen der Ansatz für den Passkey-Login. Je nach Anwendungsfall mag ein manueller Login für kleinere Plattformen ausreichend sein, aber für größere UX-orientierte Unternehmen wird ein Identifier-First-Ansatz empfohlen, der einen Passkey-Login anbietet, nachdem der primäre Identifier (höchstwahrscheinlich E-Mail) eingegeben wurde.

3.1 Manueller Passkey-Login: Benutzerinitiierter Ansatz#

3.1.1 Was ist der benutzerinitiierte Ansatz?#

Auf kleineren Plattformen oder Plattformen, die nicht auf eine hohe Passkey-Login-Rate fokussiert sind, beinhaltet der benutzerinitiierte Ansatz eine separate Schaltfläche „Mit Passkey anmelden“. Bei diesem Ansatz liegt die Verantwortung für die Nutzung von Passkeys vollständig beim Benutzer. Nachdem der Benutzer seinem Konto einen Passkey hinzugefügt hat, muss er daran denken, auf „Mit Passkey anmelden“ zu klicken, um sich damit einzuloggen.

Der Screenshot zeigt die Passkey-Implementierung von https://my.gov.au, welche den manuellen Passkey-Login-Ansatz nutzt. Obwohl dieser Ansatz einfacher zu implementieren ist, da das Backend nicht feststellen muss, ob ein Passkey-Login möglich ist, führt er typischerweise zu deutlich niedrigeren Passkey-Login-Raten. Dies liegt daran, dass er stark von der Eigeninitiative des Benutzers abhängt und Verbraucher sich möglicherweise nicht daran erinnern oder nicht sicher sind, auf welcher Plattform oder in welchem Cloud-Speicher sich ihre Passkeys befinden. Dieser Ansatz zwingt den Benutzer zum Nachdenken. Lassen Sie uns im nächsten Abschnitt einen Blick darauf werfen, welche möglichen Fallback-Gelegenheiten es bei diesem Ansatz gibt.

3.1.2 Fallbacks#

Fallbacks sind in jedem System unerlässlich, in dem die Möglichkeit eines fehlgeschlagenen Passkey-Zugriffs besteht. Beim manuellen Passkey-Login-Ansatz können Dialoge und Fallbacks nicht individuell verwaltet werden, da alle Login-Optionen gleichzeitig angezeigt werden und Passkeys im Ermessen des Benutzers ausgewählt werden. Dies führt zu mehreren Herausforderungen:

• Unintuitive Fehler: Die Fehlermeldungen, auf die Benutzer stoßen, wenn Passkeys nicht verfügbar sind oder falsch eingerichtet wurden, sind oft unklar und können Verwirrung stiften. Benutzer verstehen möglicherweise nicht, warum sie den Passkey nicht verwenden können oder was schiefgelaufen ist, was zu Frustration führt.
• Sackgassen: Benutzer können in Sackgassen geraten, in denen sie nicht fortfahren können. Wenn Passkeys fehlen oder nicht zugänglich sind, erhalten Benutzer möglicherweise keine klare Anleitung zum weiteren Vorgehen oder zur Wiederherstellung des Zugriffs, was sie dazu veranlasst, den Login-Vorgang abzubrechen.
• Fehlende Führung: In diesen Situationen kann das System keine hilfreichen Anweisungen geben, um Benutzer zu einer alternativen Authentifizierungsmethode zu führen. Benutzer sind sich selbst überlassen, um herauszufinden, wie sie das Problem lösen können, was die Benutzererfahrung verschlechtert.

Das obige Beispiel zeigt, wie verwirrend Fehlermeldungen von Windows 11 sind, wenn Passkeys auf dem Plattform-Authenticator nicht gefunden werden. Das System geht möglicherweise davon aus, dass sich der Passkey auf einem Sicherheitsschlüssel (Security Key) oder einem anderen Gerät befindet. Dieser Prozess kann für Benutzer, die mit solchen Authentifizierungsabläufen nicht vertraut sind, verwirrend sein, insbesondere wenn sie noch nie einen Sicherheitsschlüssel verwendet oder einen Passkey erstellt haben.

Wenn auf dem Plattform-Authenticator keine Passkeys gefunden werden, gehen das Betriebssystem und der Browser davon aus, dass sie woanders existieren müssen, was zu weiterer Verwirrung führt, falls der Benutzer noch gar keinen Passkey erstellt hat. Conditional UI kann helfen, indem vorhandene Passkeys angezeigt werden, aber dies hilft nur, wenn Passkeys tatsächlich existieren. Für die beste Passkey-Erfahrung sollte das Backend entscheiden, ob ein Passkey-Login ausgelöst werden soll, nachdem der Benutzer seinen primären Identifier bereitgestellt hat.

3.2 Automatischer Passkey-Login: Identifier-First-Ansatz#

3.2.1 Was ist der Identifier-First-Ansatz?#

Beim Identifier-First-Ansatz werden Benutzer aufgefordert, ihren primären Identifier, wie z. B. eine E-Mail oder eine Telefonnummer, anzugeben, bevor das System bestimmt, ob ein Passkey-Login möglich ist. Nachdem der Identifier verifiziert wurde, schlägt das System automatisch die am besten geeignete Login-Methode vor, einschließlich Passkeys, sofern diese verfügbar und zugänglich sind. Dieser Ansatz ist benutzerfreundlicher, da er den Benutzern die Notwendigkeit abnimmt, sich an die Auswahl der Option „Mit Passkey anmelden“ erinnern zu müssen, und er steigert die Akzeptanzrate durch eine Optimierung des Prozesses.

Google Identifier-First Sign-In

Google Passkey Sign-In

Die obigen Screenshots zeigen das Login-Verhalten eines Google-Logins für ein Konto, bei dem ein Passkey auf einem macOS-Gerät verknüpft ist. Google verfolgt ebenfalls den Identifier-First-Ansatz und hat festgestellt, dass ein Passkey-Login sehr wahrscheinlich möglich sein wird:

1. Passkey-Plattformunterstützung: Die zugrundeliegende Plattform unterstützt einen Plattform-Authenticator, daher kann ein Login möglich sein.
2. Passkey ist zugänglich: Der Passkey wird sehr wahrscheinlich auf diesem Client (macOS) zugänglich sein, da er auf einem macOS-System erstellt wurde.

Folglich wird automatisch ein Passkey-Login gestartet, der den Benutzer zur bestmöglichen Erfahrung führt. Dies folgt der Strategie „Don't make me think“.

3.2.2 Fehlende Unterstützung der Passkey-Plattform oder Passkey-Zugänglichkeit#

Das System bestimmt, ob ein Passkey-Login möglich ist. Für den Fall:

• Es existiert kein Passkey: Der Benutzer hat noch keinen Passkey für sein Konto erstellt.
• Passkeys sind nicht zugänglich: Die Passkeys, die der Benutzer erstellt hat, sind höchstwahrscheinlich auf diesem Client nicht verfügbar (z. B. hat der Benutzer nur einen MacOS-Passkey und loggt sich nun von Windows aus ein).
• Passkey-Authentifizierung wird nicht unterstützt: Der aktuelle Client unterstützt keine Plattform-Authenticatoren und es ist auch sehr unwahrscheinlich, dass er eine geräteübergreifende Authentifizierung (Cross-Device-Authentication) via QR-Code unterstützt.

wird die Entscheidung lauten, dass ein erfolgreicher Passkey-Login unwahrscheinlich ist und daher die Fallback-Optionen automatisch bereitgestellt werden, ohne einen Passkey-Login auszulösen. Dieser Ansatz ist viel benutzerfreundlicher, da er die Notwendigkeit für Benutzer eliminiert, sich an die Auswahl der Option „Mit Passkey anmelden“ erinnern zu müssen, die Akzeptanzrate durch die Rationalisierung des Prozesses erhöht und das Worst-Case-Szenario vermeidet, bei dem dem Benutzer eine verwirrende Sackgasse angezeigt wird.

Im obigen Beispiel fällt der Login auf ein Passwort zurück und fordert dann basierend auf dem Status und der Sicherheit des Kontos weitere Authentifizierungsfaktoren an, da es sich bei dem Client um ein Windows 11-Gerät handelt, das wahrscheinlich keinen Zugriff auf die macOS-Passkeys hat. Je nach den Sicherheitsanforderungen Ihres Authentifizierungssystems haben Sie die volle Kontrolle darüber, welche Authentifizierungsmethode in einem solchen Fall ausgelöst werden soll (z. B. die letzte erfolgreiche Nicht-Passkey-Authentifizierungsoption).

3.2.3 Abbrüche der Passkey-Zeremonie#

Wenn ein Benutzer während eines Web-Logins auf einen Authentifizierungsbildschirm stößt, kann er überrascht oder überfordert sein, besonders wenn er eine passkeybasierte Authentifizierung zum ersten Mal verwendet. Dies kann dazu führen, dass Benutzer den Authentifizierungsvorgang abbrechen, nicht wegen eines Fehlers, sondern einfach, weil sie unsicher sind, was gerade passiert. Es ist von entscheidender Bedeutung, dieses Verhalten einzuplanen und den ersten Abbruch nicht als Fehler, sondern als normales Ereignis zu behandeln:

Der erste Abbruchbildschirm sollte klar und auf beruhigende Weise erklären, was passiert, und dem Benutzer empfehlen, den Vorgang erneut zu versuchen (siehe Google-Beispiel oben). Dieser Bildschirm sollte so gestaltet sein, dass er Ängste minimiert und den Abbruch als normalen, erwarteten Teil der Benutzererfahrung behandelt. Viele Benutzer brechen möglicherweise einfach deshalb ab, weil sie den Authentifizierungsbildschirm nicht erkannt haben oder mit dem Prozess nicht vertraut waren. Daher sollte ein erneuter Versuch der Standardvorschlag sein.

Tritt jedoch ein zweiter Abbruch auf, sollte die Situation anders behandelt werden. Der zweite Abbruch könnte darauf hindeuten, dass tatsächlich etwas schiefgelaufen ist – sei es ein Problem mit dem Plattform-Authenticator, dass der Benutzer keinen geeigneten Passkey finden kann oder dass ein technischer Fehler in der WebAuthn-Zeremonie vorliegt. An diesem Punkt sollte das System einen anderen Bildschirm präsentieren, der erklärt, dass ein Problem aufgetreten ist, und Fallback-Optionen etwas stärker in den Vordergrund rücken:

Der zweite Abbruchbildschirm sollte den Benutzer ermutigen, zu einer alternativen Authentifizierungsmethode zu wechseln. Er sollte sicherstellen, dass sich der Benutzer weiterhin erfolgreich anmelden kann, ohne weitere Frustration zu verursachen. Wie wir auf dem Bildschirm oben sehen können, schlägt Google weiterhin „Erneut versuchen“ vor, zeigt dem Benutzer aber gleichzeitig, dass wahrscheinlich etwas schiefgelaufen ist.

3.3 Vergleich der Ansätze zur Passkey-Implementierung#

Die folgende Tabelle hilft dabei, die verschiedenen Ansätze zu vergleichen, indem sie die wichtigsten Eigenschaften zusammenfasst:

Do-it-yourself-Ansätze folgen normalerweise dem manuellen Passkey-Login-Ansatz und verlassen sich auf Conditional UI und die aktive Entscheidung des Benutzers (Opt-in) für Passkeys, was zu sehr niedrigen Passkey-Login-Raten und frustrierten Benutzern führt. Der Identifier-First-Ansatz erfordert die Etablierung einer durchdachten Gerätelogik zusätzlich zur Conditional UI. Hier kann Corbado Ihnen helfen. Der Aufbau einer eigenen Gerätelogik und Passkey Intelligence wird nicht empfohlen, da dieses Regelwerk ständige Anpassungen und Feinabstimmungen auf neue Geräte, neue WebAuthn- & Cloud-Sync-Funktionalitäten (z. B. GPM-Passkeys) erfordert.

4. Passkey Recovery (Wiederherstellung)#

Passkey Recovery ist ein entscheidender Aspekt zur Aufrechterhaltung der Sicherheit und der Benutzererfahrung, wenn Benutzer den Zugriff auf ihre Passkeys verlieren. Dies ist besonders wichtig in Systemen, die auf MFA angewiesen sind. In MFA-Fällen müssen Recovery-Prozesse sicherstellen, dass die Sicherheit gewahrt bleibt, während den Benutzern ermöglicht wird, den Zugang zu ihren Konten wiederzuerlangen. Der Recovery-Ansatz muss basierend auf der im System verwendeten Authentifizierungsstufe angepasst werden.

4.1 Single-Factor Recovery und Multi-Factor Recovery#

Um die Sicherheit in SFA-Systemen aufrechtzuerhalten, beinhaltet das Recovery im Allgemeinen den Nachweis der Kontrolle über einen Identifier wie eine E-Mail-Adresse oder eine Handynummer.

• E-Mail-OTP: Ein OTP wird an die registrierte E-Mail-Adresse des Benutzers gesendet. Nach der Verifizierung kann der Benutzer so den Zugang wiedererlangen und einen neuen Passkey erstellen.
• SMS-OTP: Ähnlich wie bei der E-Mail-Wiederherstellung wird ein OTP an die registrierte Handynummer gesendet. Der Benutzer kann dieses OTP verwenden, um den Zugang zu seinem Konto wiederzuerlangen.

Obwohl diese Methoden unkompliziert sind, beruhen sie darauf, die Kontaktinformationen des Benutzers auf dem neuesten Stand zu halten. Daher ist es unerlässlich, Benutzer bei Routine-Logins regelmäßig aufzufordern, ihre E-Mail und Telefonnummer zu verifizieren.

In Multi-Faktor-Authentifizierungs-Systemen wird das Recovery komplexer. Da MFA auf mehreren unabhängigen Faktoren beruht (z. B. Passkeys, Social Login und OTPs), sollten Benutzer den Zugang nicht nur deshalb verlieren, weil ein Faktor (wie ein Passkey) nicht verfügbar ist.

• Verwendung alternativer Faktoren: Geht der Passkey verloren, kann sich der Benutzer mit zwei anderen Faktoren authentifizieren, beispielsweise mit einem Passwort + SMS-OTP oder einer Authenticator-App. Sobald er authentifiziert ist, kann er einen neuen Passkey erstellen.
• Verwendung anderer Passkeys: Falls der Benutzer andere Geräte mit Passkeys besitzt, könnte er diese verwenden, um mit entsprechenden Hinweisen den Zugang wiederzuerlangen (z. B. durch die Aufforderung, einen Passkey von einem iPhone zu verwenden).
• Erstellung neuer Passkeys: Nach der Authentifizierung mit der Recovery-Methode sollte der Benutzer angeleitet werden, einen neuen Passkey zu erstellen, um sicherzustellen, dass das MFA-Setup intakt bleibt.

Sowohl für SFA- als auch für MFA-Systeme ist der Schlüssel sicherzustellen, dass Recovery-Prozesse robust und sicher sind und gleichzeitig die Reibung für den Benutzer minimieren.

4.2 Intelligentes MFA Recovery: Digitalisierung der MFA-Recovery-Kosten#

In Systemen, die sensible personenbezogene Daten verarbeiten, in regulierten Branchen oder bei Behördendiensten reichen herkömmliche E-Mail-OTPs und Handynummern-OTPs für das Recovery möglicherweise nicht immer aus oder sind nicht verfügbar. In solchen Fällen bieten Mechanismen für das intelligente MFA Recovery fortschrittliche Methoden zur Kontowiederherstellung, die hohe Sicherheitsstandards aufrechterhalten und Benutzern gleichzeitig ein nahtloses Erlebnis bieten.

Eine der effektivsten Methoden ist die Selfie-Identifikation mit einem Liveness-Check. Bei diesem Prozess fotografiert der Benutzer seinen Ausweis. Zusätzlich stellt ein Selfie-Liveness-Check sicher, dass das Selfie in Echtzeit aufgenommen wird, und bestätigt, dass der Benutzer physisch anwesend ist und mit dem fotografierten Ausweis übereinstimmt. Auf diese Weise wird Betrug durch statische Bilder oder gestohlene Ausweise verhindert. Je nach verwendeter Technologie erfolgt ein Liveness-Check entweder durch die Aufnahme eines kurzen Videos, in dem der Abstand zur Kamera verändert wird, oder durch eine Drehung des Kopfes um 180 Grad (z. B. Apple Face ID).

Diese Methode kann besonders nützlich sein, wenn herkömmliche Recovery-Methoden wie E-Mail- oder SMS-OTPs nicht verfügbar oder ebenfalls veraltet sind. Hier ist beispielsweise ein Beispiel für die Aufnahme eines Selfies, gefolgt von einem Liveness-Check von Onfido:

Beispiel: Selfie-Ident mit Liveness Check von Onfido

• Behördensysteme, regulierte Branchen oder große kommerzielle Dienste verfügen über persönliche Daten, die zur Verifizierung der auf dem Ausweis verfügbaren Informationen verwendet werden können. Falls z. B. das Geburtsdatum nicht verfügbar ist, können die über den Ausweis gesammelten Informationen als Faktor im manuellen Recovery-Prozess verwendet werden.

Zusätzlich können weitere intelligente Recovery-Methoden Folgendes umfassen:

• Geräteübergreifendes Recovery (Cross-Device Recovery): Verfügt ein Benutzer über ein vertrauenswürdiges Zweitgerät, kann er sein Konto wiederherstellen, indem er einen QR-Code scannt.
• Bekannte Umgebungen: Benutzer, die noch Zugriff auf dasselbe Gerät haben, das sie in der Vergangenheit erfolgreich verwendet haben, können durch die Nutzung dieses Geräts zusätzliche absichernde Faktoren bereitstellen. Dadurch erbringen sie den Nachweis, dass sie vom selben Gerät, Anbieter und Standort aus agieren, um den manuellen Recovery-Prozess zu unterstützen. Ein Ansatz, den Google für die Gmail-Kontowiederherstellung (Gmail Account Recovery) verwendet.
• Digital Credentials API: Angesichts der zunehmenden Verbreitung von ID-Wallets wird erwartet, dass die direkte Verifizierung über diese API eine wachsende Rolle bei der sicheren und benutzerfreundlichen Kontowiederherstellung spielen wird.

Intelligente MFA-Recovery-Methoden zielen darauf ab, Benutzern sichere, intuitive Wege zu bieten, um den Zugriff auf ihre Konten wiederzuerlangen, insbesondere beim Umgang mit hochsensiblen oder regulierten Informationen. Diese Ansätze stellen sicher, dass Benutzer ihren Zugriff auch dann noch sicher und effizient wiederherstellen können, wenn herkömmliche Methoden wie E-Mail- oder Telefon-Recovery nicht zur Verfügung stehen. Intelligentes Recovery hilft dabei, die Kosten für das MFA Recovery zu senken.

4.3 MFA-Recovery-Häufigkeiten: Telefonnummer vs. Passkey#

Es ist wichtig im Hinterkopf zu behalten, dass, da Passkeys in der Cloud synchronisiert werden, die Kosten für ein MFA-Recovery über einen Zeitraum von 36 Monaten viel geringer sind, da der Wechsel der Handynummer sehr viel häufiger vorkommt als der Wechsel von Apple zu Android oder umgekehrt. Im Falle eines Telefon- oder Handyvertragswechsels werden die Passkeys wiederhergestellt.

Daher tritt ein Verlust des Zugriffs auf synchronisierte Passkeys seltener auf als der Verlust des Zugriffs auf die Handynummer, was den meisten Recovery-Schmerz bei herkömmlichen verbraucherorientierten MFA-Systemen verursacht.

Dennoch verursachen solche Fälle mit wachsender Benutzerbasis signifikante manuelle Supportkosten und sollten mit einer digitalen Lösung gehandhabt werden, die wir uns im nächsten Abschnitt ansehen werden.

5. Empfehlungen für Produktmanager und Entwickler#

Wenn Sie Passkeys in Ihr Authentifizierungssystem integrieren, ist es entscheidend, sowohl Fallback-Optionen als auch Recovery-Strategien sorgfältig zu planen, um ein hohes Maß an Sicherheit aufrechtzuerhalten und gleichzeitig eine nahtlose Benutzererfahrung zu gewährleisten. Um die Login-Rate beim Passkey-Login zu maximieren, sollten Sie die folgenden Empfehlungen berücksichtigen:

• Entscheiden Sie sich für den Identifier-First-Ansatz: Dieser Ansatz ist benutzerfreundlicher und reduziert Reibungsverluste beim Login-Prozess. Durch die Aufforderung an die Benutzer, zuerst ihren primären Identifier einzugeben (z. B. E-Mail oder Telefonnummer), kann das System automatisch ermitteln, ob ein Passkey-Login möglich ist. Dies gewährleistet ein reibungsloses, intuitives Login-Erlebnis, ohne sich darauf zu verlassen, dass der Benutzer manuell eine Passkey-Option wählt.
• Verwenden Sie erklärende Abbruchbildschirme für eine bessere Benutzererfahrung: Auch wenn die Sicherheit oberste Priorität haben sollte, ist es wichtig, einen Prozess zu entwerfen, der dem Benutzer hilft, Passkeys anzunehmen. Stellen Sie sicher, dass Abbrüche der Zeremonie beim ersten Mal als normal behandelt werden, und geben Sie eine klare Anleitung für einen erneuten Versuch.
• Halten Sie Fallback- und Recovery-Optionen sicher: Stellen Sie sicher, dass Fallback-Methoden (wie E-Mail-OTP und/oder SMS-OTP) der Sicherheitsstufe der primären Authentifizierungsmethode entsprechen. Beispielsweise sollte bei einem MFA-System, das Passkeys verwendet, das Fallback ebenfalls mehrere Faktoren erfordern, um denselben Sicherheitsstandard aufrechtzuerhalten.
• Automatisieren Sie regelmäßige Recovery-Aufforderungen: Fordern Sie Benutzer beim Login regelmäßig auf, ihre Kontaktinformationen (E-Mail-Adresse oder Telefonnummer) zu verifizieren. So stellen Sie sicher, dass die Recovery-Optionen aktuell bleiben, wenn sie Passkeys verwenden. Dies verringert die Wahrscheinlichkeit, dass Benutzer aufgrund veralteter Recovery-Methoden aus ihren Konten ausgesperrt werden.
• Erwägen Sie intelligente Recovery-Methoden für mehr Sicherheit und reduzierte Support-Recovery-Kosten: Für regulierte Branchen oder Systeme, die auf persönliche Daten zugreifen können, um diese mit einer Online-Identifikation abzugleichen, sollten Sie fortschrittliche Recovery-Methoden wie die Selfie-Identifikation mit Liveness-Checks in Betracht ziehen. Diese Methode kann, abhängig von Ihren Sicherheitsanforderungen, zusätzliche Sicherheitsebenen bieten und den Recovery-Prozess gleichzeitig intuitiv und benutzerfreundlich halten.

Die Maximierung der Passkey-Login-Rate hängt davon ab, wie gut Sie diese Elemente umsetzen. Die Gewährleistung reibungsloser Fallback- und Recovery-Optionen wird den Benutzern Vertrauen geben, Passkeys als ihre primäre Authentifizierungsmethode zu nutzen.

6. Was Corbado für Sie tun kann: UI-Komponenten & Passkey Intelligence#

Corbado bietet alles Notwendige, um den Identifier-First-Ansatz für Greenfield-Projekte zu implementieren, die ein komplett neues Authentifizierungssystem benötigen, sowie für bestehende Projekte, die Passkeys in ein bestehendes Authentifizierungssystem integrieren müssen.

6.1 UI-Komponenten für verschiedene Anwendungsfälle#

Beide Produkte bieten UI-Komponenten, die auf Ihre Bedürfnisse zugeschnitten werden können:

1. Corbado Complete: Starten Sie Ihr Projekt mit Passkey-First-Authentifizierung
   Dies ist unser vollständiges Authentifizierungssystem, das einen nahtlosen Identifier-First-Ansatz beinhaltet, um den Login-Prozess zu optimieren. Corbado Complete ermöglicht ein sicheres und benutzerfreundliches Erlebnis, indem es automatisch ermittelt, ob ein Passkey-Login möglich ist, nachdem der Benutzer seinen Identifier angegeben hat. Dies reduziert Reibungsverluste und stellt ein reibungsloses Login-Erlebnis sicher, das für die Maximierung der Passkey-Akzeptanz entscheidend ist.
2. Corbado Connect: Fügen Sie Passkeys ohne Migration zu jeder App hinzu
   Für Unternehmen, die bereits über etablierte Authentifizierungsprozesse verfügen und Passkeys als Erweiterung hinzufügen möchten, bietet Corbado Connect eine Add-on-Lösung für Single-Factor- und Multi-Factor-Strategien. Dieser Ansatz ergänzt Ihre bestehende Infrastruktur, indem er Passkeys nahtlos als sichere und bequeme Option integriert, sodass sich Benutzer über Passkeys authentifizieren können, ohne Ihr aktuelles System überarbeiten zu müssen. Corbado Connect kann beispielsweise nahtlos in Amazon Cognito eingebettet werden.

Wir richten unsere Methoden strikt nach Branchenführern wie Google und anderen prominenten Akteuren im Big-Tech-Bereich aus, insbesondere zugeschnitten auf verbraucherorientierte Unternehmen.

6.2 Passkey Intelligence ermöglicht den Identifier-First-Ansatz#

Unser Ziel ist es nicht nur, die Passkey-Adoption (d. h. die Erstellung von Passkeys) zu maximieren, sondern auch sicherzustellen, dass diese Passkeys aktiv genutzt werden, um hohe Login-Raten zu erzielen (und somit die Sicherheit zu erhöhen und SMS-OTP-Kosten zu senken). Unsere UI-Komponenten sind mit Blick auf den Identifier-First-Ansatz entwickelt worden und direkt mit unserer Passkey Intelligence verbunden. Diese entscheidet über die Verfügbarkeit und Zugänglichkeit von Passkeys basierend auf der Client-Umgebung und vorhandenen Passkeys. Sie unterstützen alle besprochenen Fallback- und Recovery-Funktionalitäten. Die folgenden Bildschirme zeigen unsere Abbruch- & Retry-Logik:

Erster Passkey-Abbruch

Zweiter Passkey-Abbruch

Indem wir uns sowohl auf die Passkey-Adoption als auch auf die Passkey-Nutzung konzentrieren, helfen wir Ihnen, ein Gleichgewicht zwischen Sicherheit und Benutzererfahrung zu erreichen, und stellen sicher, dass Benutzer weiterhin reibungslos mit Passkeys interagieren.

7. Fazit#

In diesem Leitfaden haben wir die verschiedenen Fallback- und Recovery-Strategien infolge der Integration von Passkeys in ein Authentifizierungssystem untersucht. Zu den in der Einleitung gestellten Schlüsselfragen wurde durchgehend Stellung bezogen:

• Welche Fallback-Szenarien existieren? Es können mehrere Fallback-Szenarien auftreten, wie z. B. fehlende Passkey-Unterstützung oder Passkeys, die auf einem bestimmten Gerät nicht zugänglich sind. Um die Sicherheit zu wahren und eine reibungslose UX zu bieten, sollten Fallback-Optionen wie E-Mail- oder SMS-OTP verfügbar sein, wenn ein Passkey-Login nicht möglich ist.
• Wie sollte das Recovery gehandhabt werden? Recovery-Prozesse sollten so gestaltet sein, dass sie dem Sicherheitsniveau des Authentifizierungssystems entsprechen. In SFA-Systemen können E-Mail- oder SMS-OTP ausreichen, während in MFA-Systemen alternative Faktoren verwendet werden müssen, um den Zugang wiederzuerlangen und einen neuen Passkey zu erstellen. In stark regulierten oder sensiblen Umgebungen bieten intelligente Recovery-Methoden, wie die Selfie-Identifikation mit Liveness-Checks, zusätzliche Sicherheit.

Durch die Befolgung der in diesem Leitfaden skizzierten Best Practices können Produktmanager und Entwickler robuste passkeybasierte Authentifizierungssysteme entwerfen, die Benutzern ein sicheres und dennoch nahtloses Login-Erlebnis bieten. Sicherheit muss nicht auf Kosten der Benutzererfahrung gehen – beides kann mit durchdachtem Design und Planung erreicht werden.

Über Corbado

Corbado ist die Passkey Intelligence Platform für CIAM-Teams, die Consumer-Authentifizierung im großen Maßstab betreiben. Wir zeigen Ihnen, was IDP-Logs und generische Analytics-Tools nicht sehen können: welche Geräte, OS-Versionen, Browser und Credential-Manager Passkeys unterstützen, warum Enrollments nicht zu Logins werden, wo der WebAuthn-Flow scheitert und wann ein OS- oder Browser-Update den Login still und leise unterbricht – und das alles, ohne Okta, Auth0, Ping, Cognito oder Ihren In-House-IDP zu ersetzen. Zwei Produkte: Corbado Observe ergänzt Observability für Passkeys und jede andere Login-Methode. Corbado Connect bringt Managed Passkeys mit integrierter Analytics (neben Ihrem IDP). VicRoads betreibt Passkeys für über 5 Mio. Nutzer mit Corbado (+80 % Passkey-Aktivierung). Mit einem Passkey-Experten sprechen →

Häufig gestellte Fragen (FAQ)#

Wie geht der Identifier-First-Ansatz mit dem Passkey-Login um, wenn auf dem aktuellen Gerät kein Passkey verfügbar ist?#

Wenn ein Passkey wahrscheinlich nicht zugänglich ist (z. B. ein macOS-Passkey, auf den von einem Windows-Gerät zugegriffen wird), überspringt das System automatisch die Passkey-Aufforderung und präsentiert stattdessen Fallback-Optionen wie Passwort oder OTP. Dies vermeidet verwirrende Sackgassen, indem der Passkey-Login nur dann ausgelöst wird, wenn ein Erfolg wahrscheinlich ist, und folgt der „Don't make me think“-Strategie.

Was sollte passieren, wenn ein Benutzer eine Passkey-Authentifizierung mittendrin abbricht?#

Der erste Abbruch sollte als normales Ereignis behandelt werden, mit einem beruhigenden Bildschirm, der den Benutzer ermutigt, es erneut zu versuchen, da viele Benutzer einfach abbrechen, weil sie mit dem Authentifizierungsbildschirm nicht vertraut sind. Tritt ein zweiter Abbruch auf, sollte das System Fallback-Authentifizierungsoptionen anzeigen, da dies auf ein tatsächliches Problem mit dem Plattform-Authenticator oder der Passkey-Verfügbarkeit hinweisen kann.

Welche Recovery-Optionen gibt es für MFA-Systeme, wenn ein Benutzer den Zugriff auf seinen Passkey verliert?#

In MFA-Systemen können Benutzer den Zugang wiederherstellen, indem sie sich mit zwei alternativen Faktoren wie einem Passwort plus SMS-OTP oder durch die Verwendung eines Passkeys von einem anderen vertrauenswürdigen Gerät authentifizieren und dann einen neuen Passkey erstellen. Für regulierte Branchen, in denen herkömmliche Recovery-Methoden nicht verfügbar sind, bieten intelligente Methoden wie die Selfie-Identifikation mit Liveness-Checks einen zusätzlichen sicheren Wiederherstellungsweg.

Warum führt der Ansatz mit der manuellen Schaltfläche „Mit Passkey anmelden“ zu einer geringeren Akzeptanz im Vergleich zum Identifier-First-Ansatz?#

Der manuelle Ansatz überträgt den Benutzern die volle Verantwortung, sich an die Passkey-Option zu erinnern und sie selbst auszuwählen, was in der Regel zu deutlich niedrigeren Passkey-Login-Raten führt. Benutzer können auch auf unklare Fehlermeldungen stoßen, wenn Passkeys auf dem Plattform-Authenticator nicht gefunden werden, was zu Frustration und abgebrochenen Login-Versuchen führt.