WebAuthn Passkey QR-Codes & Bluetooth: Hybrid Transport

Passkeys ersetzen zunehmend Passwörter als De-facto-Standard bei der Benutzerauthentifizierung. Im Gegensatz zu herkömmlichen Passwörtern sind Passkeys an ein Ökosystem gebunden (z. B. iCloud-Schlüsselbund, Google Passwortmanager, Windows Hello oder ein Passwort-Manager wie 1Password oder Dashlane); sie sind nicht dafür gedacht, auswendig gelernt zu werden, sondern sind so konzipiert, dass sie sich nahtlos in Ihre Geräte integrieren und ein hervorragendes sofort einsatzbereites Benutzererlebnis bieten.

Stellen Sie sich vor, Sie sind nicht an Ihrem persönlichen Computer, vielleicht an einem öffentlichen Terminal oder dem Laptop eines Freundes, und müssen sich in Ihr passkey-geschütztes Konto einloggen. Dieses Szenario ist recht häufig und erfordert eine sichere und dennoch bequeme Authentifizierungsmethode, aber bei Passkeys wissen viele Leute nicht, was sie tun sollen, da ihr Passkey in dieser Situation nicht sofort verfügbar ist. Eine der Passkey-Funktionen, die Ihnen in einer solchen Situation helfen, ist die Möglichkeit, Ihre Passkeys über mehrere Geräte hinweg durch die Verwendung von QR-Codes und Bluetooth-Technologie zu nutzen. Dieser Prozess ist in der WebAuthn-Spezifikation formell als Hybrid Transport bekannt (in früheren Versionen der Spezifikation wurde er als Cloud-Assisted Bluetooth Low Energy caBLE bezeichnet).

Der Prozess ist unkompliziert: Sie benötigen ein Gerät, auf dem Ihre Passkeys gespeichert sind und das Fotos aufnehmen kann, also höchstwahrscheinlich ein Smartphone oder Tablet. Dieses Gerät kann einen Tunnel zum neuen Gerät nur für diesen einen Authentifizierungsvorgang öffnen. Dies erhält nicht nur die Integrität Ihres Passkeys, sondern stellt auch sicher, dass der Zugriff auf Ihr Konto auf neuen Geräten gewährt werden kann, egal wo Sie sind oder wessen Gerät Sie zum Einloggen verwenden möchten.

Allerdings ist diese plattformübergreifende Authentifizierungsfunktion von Passkeys sowohl in ihrem Nutzen als auch in ihrer technischen Umsetzung von Missverständnissen und Verwirrung umgeben. Das ist mir kürzlich wieder aufgefallen, als ich ein lokales IT-Sicherheits-Meetup besuchte. Mit diesem Artikel möchten wir die Komplexität entwirren und Empfehlungen zur Implementierung dieses plattformübergreifenden Passkey-Authentifizierungsflusses (Hybrid Transport) geben, um sicherzustellen, dass Sie Ihren Benutzern das beste Anmeldeerlebnis bieten können.

Passkeys sind eine Form der Benutzerauthentifizierung, die das traditionelle Passwort durch ein sichereres und bequemeres kryptografisches Paar aus öffentlichem und privatem Schlüssel ersetzt. Dieses Schlüsselpaar ist für jeden Benutzer einzigartig und wird verwendet, um die Identität ohne den Aufwand des Erinnerns komplexer Passwörter zu überprüfen.

Die Vorteile von Passkeys sind im Vergleich zu ihren Passwort-Vorgängern zahlreich. Sie reduzieren das Risiko von Phishing erheblich, da sie nicht dazu verleitet werden können, mit einer gefälschten Website geteilt zu werden. Darüber hinaus sind sie immun gegen Brute-Force- und Wörterbuchangriffe, die gängige Methoden zum Knacken von Passwörtern sind. Passkeys sind auch benutzerfreundlicher, da sie die Notwendigkeit eliminieren, sich eine lange Liste von Passwörtern zu merken oder zu verwalten.

Passkeys werden in Cloud-Konten synchronisiert, wie denen, die von Google Passwortmanager oder Apple iCloud-Schlüsselbund verwaltet werden (Microsoft mit Windows Hello wird bald folgen), oder denen, die in modernen passkey-fähigen Passwort-Managern wie 1Password oder Dashlane gespeichert sind. Es ist jedoch wichtig zu wissen, dass Passkeys standardmäßig an das Ökosystem und die jeweilige Cloud-Konto-Synchronisierung gebunden sind. Die Betriebssysteme bieten keine Schnittstelle zum Exportieren der privaten Schlüssel, und in den meisten Geräten gibt es eine Hardwarekomponente, die zusätzliche Sicherheitsmaßnahmen bietet, um jeglichen Zugriff auf die privaten Schlüssel zu verhindern, z. B. die Secure Enclave auf iOS-Geräten oder das Trusted Platform Module (TPM) auf Windows-Geräten. Nur der Anbieter des Betriebssystems kann die Passkeys verschlüsselt auf andere Geräte synchronisieren (letztendlich geschützt durch die Biometrie, den Passcode oder die PIN des Benutzers). Die privaten Schlüssel können nur mit dem Passcode / der PIN wiederhergestellt und entschlüsselt werden und werden zerstört, falls es zu viele erfolglose Anmeldeversuche beim Cloud-Konto gibt (z. B. führt Apple eine Ratenbegrenzung ein, um Brute-Force-Angriffe selbst aus einer privilegierten Position im Cloud-Backend zu verhindern; Google tut dasselbe).

Dieses inhärente Design bedeutet, dass der Zugriff auf Ihre Passkeys auf einem neuen Gerät eine Herausforderung darstellen kann, wenn Passkeys nicht wie beschrieben synchronisiert werden. Genau aus diesem Grund existiert die Hybrid-Transport-Methode für die plattformübergreifende Passkey-Authentifizierung (Hybrid Transport) mit QR-Code und Bluetooth-Näherungsprüfung. Sie bietet eine sichere Brücke für Ihre Passkeys zwischen Geräten, ohne dass sie über ein Cloud-Konto / einen Passwort-Manager synchronisiert werden müssen, wodurch das Prinzip gewahrt bleibt, dass Passkeys ausschließlich beim Benutzer verbleiben können.

Die Verwendung der plattformübergreifenden Passkey-Authentifizierung (Hybrid Transport) hilft, geräteübergreifende Probleme zu überwinden, wenn ein Konto ausschließlich über Passkeys zugänglich ist. Da nicht alle Passkeys in Cloud-Konten oder Passwort-Managern synchronisiert werden, wird die Notwendigkeit einer zuverlässigen Methode für den Zugriff auf Passkeys über verschiedene Geräte hinweg kritisch, insbesondere beim Übergang zu einem neuen Gerät oder wenn der Zugriff auf einem gemeinsam genutzten Gerät erforderlich ist.

Um die plattformübergreifende Passkey-Authentifizierung (Hybrid Transport) zu ermöglichen, gibt es die folgenden Hardware-Anforderungen:

• WebAuthn-Unterstützung: Die Geräte müssen WebAuthn unterstützen. Dies ist laut unserer neuesten Passkey-Datenanalyse bereits bei 99 % der Geräte der Fall.
• Kamera zum Scannen von QR-Codes: Die Geräte benötigen eine Kamera, die QR-Codes scannen kann. Die meisten modernen Smartphones sind mit Kameras ausgestattet, die diese Funktionalität haben. Darüber hinaus benötigt die Kamera integrierte QR-Scan-Fähigkeiten (was die meisten Geräte von Haus aus haben). Wenn Ihre Kamera dies nicht unterstützt, ist auch ein Online-QR-Scanner eine gute Option. Andernfalls ist auch die Installation einer QR-Code-App in Ordnung.
• Bluetooth-Fähigkeit: Cloud-Assisted Bluetooth Low Energy (caBLE) wird verwendet, um eine nähebasierte sichere Verbindung zwischen Geräten herzustellen. Die zu suchenden Versionen sind Bluetooth 4.0 oder höher, die die caBLE-Erweiterung für WebAuthn ermöglichen.
• Internetverbindung: Auf beiden Geräten muss eine stabile Internetverbindung vorhanden sein, da der Austausch das Öffnen eines Tunnels zur Durchführung von Verifizierungsschritten beinhaltet, die eine Echtzeit-Datenübertragung erfordern.

Aus Software-Sicht gibt es die folgenden Anforderungen:

• WebAuthn-Serverkonfiguration: Offensichtlich benötigen Sie einen WebAuthn-Server, der die öffentlichen Schlüssel verwaltet. Dies beinhaltet auch, das Benutzerkonto für die Verknüpfung mit mehreren Authenticator zu aktivieren und den Server so einzurichten, dass er die Authentifizierungszeremonie initiiert.
• Web Bluetooth API: Für die Bluetooth-Näherungsprüfung müssen Sie auf die Web Bluetooth API zugreifen, die die Bluetooth-Fähigkeiten des Geräts von einem Browser aus auslöst.
• Anforderungen an das Betriebssystem: Bitte beachten Sie die folgende Tabelle zur Unterstützung der geräteübergreifenden Authentifizierung für verschiedene Betriebssysteme (Stand März 2025). Authenticator bedeutet, dass das Gerät als das Gerät dienen kann, das einen Passkey besitzt (in unserem Szenario das Smartphone). Client bezeichnet das Gerät, das den QR-Code erstellt und auf dem der Benutzer versucht, sich anzumelden (in unserem Szenario der Desktop):

Quelle: passkeys.dev

Der Prozess zur Verwendung der plattformübergreifenden Passkey-Authentifizierung (Hybrid Transport) über QR-Code sieht wie folgt aus:

Der QR-Code für die plattformübergreifende Passkey-Authentifizierung (Hybrid Transport) wird generiert, wenn ein Benutzer versucht, auf einen Dienst auf einem Gerät zuzugreifen, auf dem der registrierte Passkey nicht vorhanden ist, der Dienst aber weiß, dass der Benutzer einen Passkey haben sollte. Typischerweise wird eine Schaltfläche 'QR-Code scannen' oder ein ähnlicher Call-to-Action in der Authentifizierungsoberfläche bereitgestellt.

Auf Anfrage des Benutzers initiiert das Gerät die Erstellung eines QR-Codes. Dieser QR-Code kodiert eine eindeutige, zeitlich begrenzte Sitzungs-ID. Diese ID ist an eine Sitzung gebunden, die der authentifizierende Server vorübergehend aufrechterhält und auf den Abschluss des Authentifizierungsprozesses wartet.

Der Benutzer scannt diesen QR-Code mit einem Gerät, auf dem sein Passkey verfügbar ist. Zu den Sicherheitsmaßnahmen gehören:

• Einmalige Verwendung: Die Sitzungs-ID im QR-Code ist nur für eine einmalige Verwendung gültig, um Replay-Angriffe zu verhindern.
• Verschlüsselung: Alle Daten im QR-Code sind verschlüsselt, um sicherzustellen, dass abgefangene Kommunikation nicht von unbefugten Parteien entschlüsselt werden kann.

Der gescannte QR-Code enthält eine spezifische URI mit dem Schema FIDO, z.B.: FIDO:/07824133892604070278923969472008301099476228966286113051476699183587 6383562063181103169246410435938367110394959927031730060360967994421 343201235185697538107096654083332

Das Scannen des QR-Codes veranlasst das zweite Gerät des Benutzers (z. B. Smartphone oder Tablet), die FIDO-URI zu interpretieren und mit dem Authentifizierungsserver zu kommunizieren, wobei ein Signal gesendet wird, dass der Benutzer versucht, sich über ein neues Gerät (z. B. den Laptop des Freundes) zu authentifizieren. Diese Aktion veranlasst den Server, eine kryptografische Challenge zu generieren, die für diesen Authentifizierungsversuch einzigartig ist.

Die Challenge wird an das zweite Gerät des Benutzers (z. B. Smartphone oder Tablet) zurückgesendet, wo sein Passkey gespeichert ist. Das Gerät erstellt dann eine digitale Signatur unter Verwendung des mit dem Passkey verknüpften privaten Schlüssels, ohne dass der private Schlüssel jemals das Gerät verlässt (z. B. Smartphone oder Tablet). Die signierte Challenge (Signatur) wird dann über einen sicheren, verschlüsselten Tunnel über das Internet an den Server zurückgesendet, wodurch die Integrität und der Ursprung des Authentifizierungsversuchs überprüft werden.

Der Server validiert die Signatur unter Verwendung des entsprechenden öffentlichen Schlüssels, der bereits mit dem Konto des Benutzers verknüpft ist. Nach erfolgreicher Validierung bestätigt der Server die Authentifizierung und ermöglicht dem Benutzer den Zugriff auf den Dienst auf dem neuen Gerät.

Einige weitere wichtige Datenschutz- und Sicherheitsaspekte, die zu berücksichtigen sind:

• Kein Bluetooth-Datenaustausch, reines Internet: Es ist wichtig zu beachten, dass bei dieser QR-Code-basierten plattformübergreifenden Passkey-Authentifizierung (Hybrid Transport) Bluetooth nicht am Datenaustausch beteiligt ist. Dieser Prozess stützt sich vollständig auf eine Internetverbindung für die Übertragung verschlüsselter Daten zwischen den Geräten und dem Server. Bluetooth wird jedoch für eine Näherungsprüfung der beiden Geräte verwendet.
• Private Schlüssel verlassen das Gerät nicht: Während dieses gesamten Prozesses bleiben die privaten Schlüssel des Benutzers sicher auf seinem Gerät.
• Keine Offenlegung sensibler Daten: Während des Authentifizierungsprozesses werden keine sensiblen Passkey-Informationen oder privaten Schlüssel übertragen oder offengelegt.
• Asymmetrische Kryptographie: Der Challenge-Response-Mechanismus stellt sicher, dass nur nicht wiederverwendbare, signierte Versionen von Challenges gesendet werden, die nicht für unbefugten Zugriff ausgenutzt werden können.

Durch die Einhaltung dieser technischen und Sicherheitsprotokolle hält die QR-Code-Methode für die plattformübergreifende Passkey-Authentifizierung (Hybrid Transport) einen hohen Sicherheitsstandard aufrecht und bietet gleichzeitig eine bequeme Möglichkeit für Benutzer, ihre Identität auf neuen Geräten zu authentifizieren.

Neben dem QR-Code-Scanprozess gibt es auch die Näherungsprüfung über Bluetooth (caBLE). Die Gewissheit, dass sich Client und Authenticator physisch nahe beieinander befinden, ist einer der Hauptvorteile des WebAuthn-Protokolls. Weitere Einblicke in die Funktionsweise dieses Prozesses werden im Folgenden beschrieben:

Bluetooth Low Energy (BLE) ist eine drahtlose Kommunikationstechnologie, die für den Datenaustausch über kurze Distanzen entwickelt wurde. Es spielt eine entscheidende Rolle bei der Bestätigung der physischen Nähe von Geräten während des Authentifizierungsprozesses.

caBLE ist ein Protokoll, das die sichere Übertragung von Authentifizierungsinformationen zwischen Geräten mittels BLE ermöglicht. Bei der Verwendung von caBLE für die plattformübergreifende Passkey-Authentifizierung (Hybrid Transport) bestätigt das Gerät, das den Passkey besitzt, die Nähe des anfragenden Geräts über BLE-Signale. Sobald die Nähe verifiziert ist, wird der Authentifizierungsprozess fortgesetzt, wobei BLE für eine sichere, lokale Kommunikation genutzt wird.

Das Benutzererlebnis wird verbessert, da diese Methode in der Regel weniger direkte Benutzerinteraktion erfordert; Geräte in unmittelbarer physischer Nähe erkennen sich automatisch. In puncto Sicherheit bietet caBLE einen erheblichen Vorteil – es stellt sicher, dass der Authentifizierungsprozess nur dann durchgeführt wird, wenn sich die beiden Geräte in der Nähe voneinander befinden, was verhindert, dass entfernte Angreifer den Authentifizierungsprozess initiieren.

Stellen Sie sich vor, Sie erhalten einen QR-Code, der auf eine bösartige Website umleitet. Wenn die Authentifizierung über diesen QR-Code durchgeführt wird, besteht das Risiko, dass die Sitzung oder das Cookie gekapert wird. BLE umgeht dieses Problem, indem es nicht auf einen visuellen Scan, sondern auf die physische Anwesenheit von Geräten setzt. Diese Näherungsprüfung minimiert das Risiko von Man-in-the-Middle-Angriffen, da die Näherungsprüfung nicht über das Internet oder ein visuelles Medium erfolgt.

Im Gegensatz zu anderen Methoden tauscht caBLE tatsächlich keine Authentifizierungsdaten wie Passkeys aus. Stattdessen verwendet es BLE als Bestätigungskanal, um festzustellen, dass sich die Geräte physisch nahe beieinander befinden. Diese Prüfung ist als Teil eines Multi-Faktor-Authentifizierungsprozesses konzipiert, bei dem die BLE-Nähe einer der Faktoren ist, um sicherzustellen, dass selbst wenn andere Faktoren kompromittiert sind, ohne physische Nähe kein Zugriff gewährt wird.

Durch die Integration des caBLE-Protokolls können Entwickler eine sichere und benutzerfreundliche Methode für die plattformübergreifende Passkey-Authentifizierung (Hybrid Transport) anbieten, die die Gesamtsicherheit des Authentifizierungsprozesses erhöht. Die Näherungsprüfung fügt eine zusätzliche Schutzschicht hinzu, die für Benutzer einfach ist und dennoch effektiv gegen bestimmte Arten von ausgeklügelten Cyber-Angriffen schützt.

Die folgenden Vorteile dieser plattformübergreifenden Passkey-Authentifizierungsmethode (Hybrid Transport) bestehen:

Die plattformübergreifende Passkey-Authentifizierung über QR-Code und Bluetooth (Hybrid Transport) ist eine Möglichkeit, die UX in plattformübergreifenden Szenarien zu verbessern, verglichen damit, überhaupt keine Möglichkeit anzubieten. Der Benutzerfluss ist jedoch für die meisten Benutzer absolut neu, und wir erwarten nicht, dass viele nicht-technische Benutzer verstehen, was passiert, wenn sie diesen Fluss zum ersten Mal sehen. Die einzige Ähnlichkeit bei der Einführung des QR-Code-Flusses kann mit Anmeldeflüssen für z. B. WhatsApp Web oder Discord bestehen, wo QR-Codes verwendet werden (hier ist die Funktionalität jedoch anders). Der analysierte plattformübergreifende Passkey-Authentifizierungsprozess über QR-Code / Bluetooth (Hybrid Transport) minimiert also den Benutzeraufwand im plattformübergreifenden Szenario, da keine Anmeldeinformationen manuell eingegeben werden müssen, aber der Gesamtfluss ist den meisten Benutzern dennoch unbekannt.

Die Sicherheit der plattformübergreifenden Passkey-Authentifizierung (Hybrid Transport) wird durch fortschrittliche kryptografische Techniken verstärkt. Wenn ein QR-Code gescannt oder eine Bluetooth-Verbindung zur Authentifizierung hergestellt wird, stellen kryptografische Challenges und Antworten sicher, dass nur das beabsichtigte Gerät den Authentifizierungsprozess erfolgreich abschließen kann.

Näherungsprüfungen über Bluetooth fügen eine zusätzliche Sicherheitsebene hinzu und bestätigen, dass der Authentifizierungsversuch von jemandem mit physischem Zugriff auf das sekundäre Gerät unternommen wird.

Während des plattformübergreifenden Authentifizierungsprozesses (Hybrid Transport) werden Passkeys niemals vorübergehend auf zwischengeschalteten Geräten oder Servern gespeichert, was das Risiko verhindert, dass Passkeys während des Übertragungsprozesses abgefangen oder kompromittiert werden. Die Authentifizierung erfolgt in Echtzeit, und der Passkey bleibt an das primäre Gerät des Benutzers gebunden, wodurch seine Integrität gewahrt bleibt.

Die Authentifizierungsmethoden mit QR-Code und Bluetooth bieten von Natur aus Schutz vor Phishing. Es ist weniger wahrscheinlich, dass Benutzer dazu verleitet werden, einen Passkey für eine bösartige Website bereitzustellen, da der Authentifizierungsprozess physische Aktionen erfordert, die spezifisch für die vertrauenswürdigen Geräte des Benutzers sind.

Der Prozess des Scannens eines QR-Codes oder der Verbindung über Bluetooth findet typischerweise in einer vertrauenswürdigen Umgebung statt, was die Wahrscheinlichkeit verringert, dass Benutzer versehentlich ihre Anmeldeinformationen kompromittieren.

Die folgenden Nachteile dieser plattformübergreifenden Passkey-Authentifizierungsmethode (Hybrid Transport) bestehen:

Die Einführung jeder neuen Technologie kann zu Verwirrung bei den Benutzern führen, insbesondere wenn die Benutzer nicht technisch versiert sind. Die plattformübergreifende Passkey-Authentifizierung über QR-Code und Bluetooth (Hybrid Transport) ist eine erhebliche Abweichung von traditionellen Authentifizierungsmethoden, und einige Benutzer könnten den neuen Prozess als schwer verständlich empfinden, was möglicherweise zu einer langsameren Akzeptanzrate führt. Wir erwarten jedoch, dass sich die Benutzer schließlich daran gewöhnen werden, sodass die Umstellung am Anfang schwieriger sein könnte und im Laufe der Zeit reibungsloser und akzeptierter wird.

Der Erfolg der plattformübergreifenden Passkey-Authentifizierung (Hybrid Transport) hängt stark davon ab, ob das Gerät des Benutzers über die erforderlichen Fähigkeiten verfügt, wie z. B. eine Kamera, die QR-Codes scannen kann, und Bluetooth-Funktionalität. Benutzer mit älteren Geräten, denen diese Funktionen fehlen, können die plattformübergreifende Passkey-Authentifizierung (Hybrid Transport) nicht nutzen, was eine digitale Kluft aufgrund von Hardware-Einschränkungen schafft.

Das Benutzerverhalten kann unvorhersehbar sein, und die Abhängigkeit von Benutzern, bestimmte Aktionen wie das Scannen eines QR-Codes oder das Aktivieren von Bluetooth durchzuführen, kann zu Benutzerfehlern führen. Zum Beispiel kann Bluetooth manchmal als UX-Herausforderung angesehen werden, aufgrund von Kopplungsproblemen, Erkennungsproblemen und allgemeinem Misstrauen der Benutzer gegenüber drahtlosen Technologien für sichere Transaktionen.

Entwickler stehen vor der Aufgabe, Systeme ständig zu aktualisieren und zu warten, um die neuesten Authentifizierungsmethoden zu unterstützen. Die Integration der plattformübergreifenden Passkey-Authentifizierung (Hybrid Transport) in bestehende Systeme erfordert, dass Entwickler über neue Standards auf dem Laufenden bleiben, neue APIs übernehmen und die Abwärtskompatibilität sicherstellen, was ressourcenintensiv und zeitaufwändig sein kann.

Für jedes neue Gerät oder jede nachfolgende Anmeldeanforderung muss ein neuer Passkey erstellt werden, wenn kein synchronisiertes Cloud-Konto wie der iCloud-Schlüsselbund oder ein Passwort-Manager verwendet wird. Dies könnte die Komplexität des Benutzererlebnisses erhöhen und zu Frustration führen, wenn Benutzer mit dem Prozess nicht vertraut sind oder wenn er nicht intuitiv gestaltet ist.

Bei der Implementierung neuer Sicherheitsmethoden wie der plattformübergreifenden Passkey-Authentifizierung (Hybrid Transport) besteht ein inhärenter Bedarf an Benutzeraufklärung. Sicherzustellen, dass Benutzer verstehen, wie sie QR-Codes und Bluetooth sicher verwenden, erfordert klare Kommunikation und möglicherweise umfangreichen Kundensupport.

Obwohl die plattformübergreifende Passkey-Authentifizierung über QR-Code und Bluetooth (Hybrid Transport) einen erheblichen Fortschritt in der Authentifizierungstechnologie darstellt, heben diese potenziellen Nachteile die Notwendigkeit eines benutzerfreundlichen Designs, robuster Unterstützungssysteme und eines schrittweisen, gut kommunizierten Übergangs von traditionellen zu innovativen Methoden hervor. Wie bei jedem technologischen Wandel wird das Gleichgewicht zwischen den Vorteilen der Innovation und ihren Herausforderungen der Schlüssel zu einer erfolgreichen Implementierung und breiten Benutzerakzeptanz sein.

Als Haftungsausschluss: Wir ignorieren in dem folgenden Test Hardware-Sicherheitsschlüssel (z. B. YubiKeys) und verwenden nur Plattform-Authenticator, die in die Geräte integriert sind (z. B. Face ID, Touch ID, Windows Hello). Im Falle von Hardware-Sicherheitsschlüsseln (z. B. YubiKey) wären die Werte für transports beispielsweise usb oder nfc.

Wir verwenden die folgenden Geräte-/Browser-Kombinationen und den Passkeys Debugger, um das Verhalten zu testen. Android wird nicht berücksichtigt, da Android nicht als Client für die plattformübergreifende Authentifizierung (Hybrid Transport) dienen kann (siehe Tabelle oben):

Um das Verhalten zu testen, erstellen wir für jede Kombination einen neuen Passkey mit den folgenden Eigenschaften:

• userName: alex muller (kein Einfluss in diesem Test)
• authenticatorAttachment: platform (da wir Hardware-Sicherheitsschlüssel wie YubiKeys ausschließen möchten)
• residentKey: preferred (kein Einfluss in diesem Test)
• userVerification: preferred (kein Einfluss in diesem Test)
• attestation: none (kein Einfluss in diesem Test)
• hints: empty (siehe Erklärung unten)
• usePRF: no (kein Einfluss in diesem Test)

Nach der erfolgreichen Erstellung des Passkeys ändern wir dann die Eingabe der allowCredentials WebAuthn-Server-Eigenschaft und initiieren eine Anmeldeanforderung. Wir möchten einen gelöschten Passkey auf dem Gerät nachahmen, auf dem wir den Passkey erstellt haben, damit das Gerät / der Browser nach einem anderen Gerät sucht, das einen Passkey über QR-Code / Bluetooth bereitstellen kann. Daher ändern wir die Credential ID und weisen den Wert CHANGED-ID zu, damit eine Übereinstimmung fehlschlägt. Darüber hinaus ändern wir die transports-Eigenschaft einer WebAuthn-Anmeldeinformation in allowCredentials und weisen für jede Geräte-/Browser-Kombination die folgenden Werte zu:

1. transports: [internal, hybrid]: Passkeys können vom Plattform-Authenticator (z. B. Face ID, Touch ID, Windows Hello) oder über plattformübergreifende Authentifizierung verwendet werden
2. transports: [internal]: Passkeys können vom Plattform-Authenticator (z. B. Face ID, Touch ID, Windows Hello) verwendet werden
3. Keine transports-Eigenschaft gesetzt: Standardverhalten, das keine Einschränkungen vorgibt

Auf der WebAuthn-Testseite gibt es auch die neue WebAuthn Level 3-Funktion für User-Agent-Hints. Diese Funktion kann das Benutzererlebnis verbessern, wenn die Relying Party bestimmte Annahmen darüber hat, wie die Anmeldeanforderung am benutzerfreundlichsten abgeschlossen werden kann. In diesem Test haben wir diese Funktion außer Acht gelassen, da sie noch nicht ausgerollt ist. Bitte sehen Sie sich die Spezifikationen für weitere Details an.

Wie erwartet, stimmt kein lokaler Passkey überein, daher wird vorgeschlagen, den QR-Code zu scannen und den Passkey auf einem anderen Gerät zu verwenden (da das System weiß, dass für diesen Benutzer ein Passkey existiert).

Verwirrenderweise wird der QR-Code auch hier angezeigt, obwohl wir nur interne Anmeldeinformationen zulassen. Wir konnten keinen triftigen Grund für dieses Verhalten finden.

Kein lokaler Passkey stimmt überein, daher wird vorgeschlagen, den QR-Code zu scannen oder einen Hardware-Sicherheitsschlüssel (z. B. YubiKey) / plattformübergreifenden Authenticator / Roaming-Authenticator zu verwenden.

Aus irgendeinem Grund erscheinen Teile des Modals auf Deutsch, was eine der installierten Sprachen ist.

Wie erwartet sind alle Formen der Passkey-Authentifizierung erlaubt: über Windows Hello, über QR-Code, über bekannte Geräte und über Hardware-Sicherheitsschlüssel.

Wie erwartet, stimmt kein lokaler Passkey überein, daher wird vorgeschlagen, den QR-Code zu scannen und den Passkey auf einem anderen Gerät zu verwenden (da das System weiß, dass für diesen Benutzer ein Passkey existiert).

Verwirrenderweise wird der QR-Code auch hier angezeigt, obwohl wir nur interne Anmeldeinformationen zulassen. Wir konnten keinen triftigen Grund für dieses Verhalten finden.

Kein lokaler Passkey stimmt überein, daher wird vorgeschlagen, den QR-Code zu scannen oder einen Hardware-Sicherheitsschlüssel (z. B. YubiKey) / plattformübergreifenden Authenticator / Roaming-Authenticator zu verwenden.

Aus irgendeinem Grund erscheinen Teile des Modals auf Deutsch, was eine der installierten Sprachen ist.

Wie erwartet sind alle Formen der Passkey-Authentifizierung erlaubt: über Windows Hello, über QR-Code, über bekannte Geräte und über Hardware-Sicherheitsschlüssel.

Beim Erstellen des Passkeys erhielten wir den folgenden Fehler (es wurde trotzdem ein Passkey erstellt):

error: TypeError: 'toJSON' called on an object that does not implement interface PublicKeyCredential.

Wie erwartet, stimmt kein lokaler Passkey überein, daher wird vorgeschlagen, den QR-Code zu scannen und den Passkey auf einem anderen Gerät zu verwenden (da das System weiß, dass für diesen Benutzer ein Passkey existiert).

Verwirrenderweise wird der QR-Code auch hier angezeigt, obwohl wir nur interne Anmeldeinformationen zulassen. Wir konnten keinen triftigen Grund für dieses Verhalten finden.

Kein lokaler Passkey stimmt überein, daher wird vorgeschlagen, den QR-Code zu scannen oder einen Hardware-Sicherheitsschlüssel (z. B. YubiKey) / plattformübergreifenden Authenticator / Roaming-Authenticator zu verwenden.

Aus irgendeinem Grund erscheinen Teile des Modals auf Deutsch, was eine der installierten Sprachen ist.

Wie erwartet sind alle Formen der Passkey-Authentifizierung erlaubt: über Windows Hello, über QR-Code, über bekannte Geräte und über Hardware-Sicherheitsschlüssel.

Wie erwartet, stimmt kein lokaler Passkey überein, daher wird vorgeschlagen, den QR-Code zu scannen und den Passkey auf einem anderen Gerät zu verwenden (da das System weiß, dass für diesen Benutzer ein Passkey existiert). Darüber hinaus können Sie direkt eines der bekannten Geräte auswählen, um einen Passkey von dort zu verwenden.

Das Modal unterscheidet sich stark von dem Pendant unter Windows in Chrome 119.

Dies ist ein erwartetes Verhalten, da wir nur die Verwendung interner Passkeys erlauben, aber keine interne Anmeldeinformation auf dem Gerät finden können (wir dürfen keine Hybrid-Passkeys verwenden). Die Passkey-Authentifizierung schlägt in diesem Schritt fehl, und in realen Implementierungen müssten Sie eine alternative Authentifizierungsmethode bereitstellen.

Kein lokaler Passkey stimmt überein, daher wird vorgeschlagen, den QR-Code zu scannen oder einen Hardware-Sicherheitsschlüssel (z. B. YubiKey) / plattformübergreifenden Authenticator / Roaming-Authenticator zu verwenden. Darüber hinaus können Sie direkt eines der bekannten Geräte auswählen, um einen Passkey von dort zu verwenden.

Das Modal unterscheidet sich stark von dem Pendant unter Windows in Chrome 119.

Wie erwartet sind alle Formen der Passkey-Authentifizierung erlaubt: über Touch ID, über QR-Code, über bekannte Geräte und über Hardware-Sicherheitsschlüssel.

Wie erwartet, stimmt kein lokaler Passkey überein, daher wird vorgeschlagen, den QR-Code zu scannen und den Passkey auf einem anderen Gerät zu verwenden (da das System weiß, dass für diesen Benutzer ein Passkey existiert).

Verwirrenderweise wird der QR-Code auch hier angezeigt, obwohl wir nur interne Anmeldeinformationen zulassen. Wir konnten keinen triftigen Grund für dieses Verhalten finden.

Kein lokaler Passkey stimmt überein, daher wird vorgeschlagen, den QR-Code zu scannen oder einen Hardware-Sicherheitsschlüssel (z. B. YubiKey) / plattformübergreifenden Authenticator / Roaming-Authenticator zu verwenden.

Wie erwartet sind die meisten Formen der Passkey-Authentifizierung erlaubt: über Touch ID, über QR-Code und über Hardware-Sicherheitsschlüssel. Aus irgendeinem Grund werden bekannte Geräte nicht angezeigt.

Wie erwartet, stimmt kein lokaler Passkey überein, daher wird vorgeschlagen, den QR-Code zu scannen und den Passkey auf einem anderen Gerät zu verwenden (da das System weiß, dass für diesen Benutzer ein Passkey existiert).

Verwirrenderweise wird der QR-Code auch hier angezeigt, obwohl wir nur interne Anmeldeinformationen zulassen. Wir konnten keinen triftigen Grund für dieses Verhalten finden.

Kein lokaler Passkey stimmt überein, daher wird vorgeschlagen, den QR-Code zu scannen oder einen Hardware-Sicherheitsschlüssel (z. B. YubiKey) / plattformübergreifenden Authenticator / Roaming-Authenticator zu verwenden.

Wie erwartet sind die meisten Formen der Passkey-Authentifizierung erlaubt: über Face ID, über QR-Code und über Hardware-Sicherheitsschlüssel. Aus irgendeinem Grund werden bekannte Geräte nicht angezeigt.

Wie erwartet, stimmt kein lokaler Passkey überein, daher wird vorgeschlagen, den QR-Code zu scannen und den Passkey auf einem anderen Gerät zu verwenden (da das System weiß, dass für diesen Benutzer ein Passkey existiert).

Verwirrenderweise wird der QR-Code auch hier angezeigt, obwohl wir nur interne Anmeldeinformationen zulassen. Wir konnten keinen triftigen Grund für dieses Verhalten finden.

Kein lokaler Passkey stimmt überein, daher wird vorgeschlagen, den QR-Code zu scannen oder einen Hardware-Sicherheitsschlüssel (z. B. YubiKey) / plattformübergreifenden Authenticator / Roaming-Authenticator zu verwenden.

Wie erwartet sind die meisten Formen der Passkey-Authentifizierung erlaubt: über Face ID, über QR-Code und über Hardware-Sicherheitsschlüssel. Aus irgendeinem Grund werden bekannte Geräte nicht angezeigt.

Im Folgenden haben wir uns für Windows 10-Geräte entschieden, eine Ebene tiefer zu gehen und zu analysieren, wie das Verhalten aussieht, wenn Bluetooth auf einem Windows 10-Rechner deaktiviert oder generell nicht verfügbar ist. Insbesondere bei älteren Desktop-Geräten ist dies immer noch ein sehr häufiges Szenario, da diese Geräte oft kein Bluetooth-Modul haben, was die plattformübergreifende Authentifizierung über QR-Code und Bluetooth unmöglich macht.

8.8.1.1 transports: [internal, hybrid]

Wie erwartet, stimmt kein lokaler Passkey überein, daher wird vorgeschlagen, den Passkey auf einem anderen Gerät zu verwenden (da das System weiß, dass für diesen Benutzer ein Passkey existiert - erster Screenshot) oder den QR-Code zu scannen (zweiter Screenshot).

8.8.1.2 transports: [internal]

Verwirrenderweise werden Sie aufgefordert, Ihren Windows Hello-PIN-Code (oder Fingerabdruck / Gesichtsscan, falls auf dem Gerät eingerichtet) einzugeben, obwohl wir die Credential ID geändert haben (es sollte also eigentlich die Anmeldeinformation nicht finden, da sie nicht in der allowCredentials-Eigenschaft angegeben ist). Nach der Eingabe des Windows Hello-PIN-Codes wird jedoch ein Fehler ausgegeben: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Aus Benutzersicht ist dies ein ziemlich verwirrendes Verhalten, macht aber Sinn, da es Informationen über die Passkeys des Benutzers ohne dessen Zustimmung preisgeben könnte.

8.8.1.3 Keine transports-Eigenschaft gesetzt

Kein lokaler Passkey stimmt überein, daher wird vorgeschlagen, den QR-Code zu scannen oder einen Hardware-Sicherheitsschlüssel (z. B. YubiKey) / plattformübergreifenden Authenticator / Roaming-Authenticator zu verwenden.

8.8.1.4 Leere allowCredentials

Wie erwartet sind alle Formen der Passkey-Authentifizierung erlaubt: über Windows Hello, über QR-Code, über bekannte Geräte und über Hardware-Sicherheitsschlüssel.

8.8.2.1 transports: [internal, hybrid]

Dies ist eine wirklich verwirrende Meldung für Benutzer, da nicht explizit angegeben wird, was sie tun und wie sie sich authentifizieren sollen. Die einzige Option, die sie haben, ist, auf „Abbrechen“ zu klicken, was dieses Szenario zu einer Sackgasse macht.

8.8.2.2 transports: [internal]

Dieses Verhalten ist dasselbe wie im Fall, dass Bluetooth aktiviert ist. Es ist sehr verwirrend, dass der Benutzer aufgefordert wird, den Windows Hello-PIN-Code (oder Fingerabdruck / Gesichtsscan, falls auf dem Gerät eingerichtet) einzugeben, obwohl wir die Credential ID geändert haben (es sollte also eigentlich die Anmeldeinformation nicht finden, da sie nicht in der allowCredentials-Eigenschaft angegeben ist). Nach der Eingabe des Windows Hello-PIN-Codes wird jedoch ein Fehler ausgegeben: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Aus Benutzersicht ist dies ein ziemlich verwirrendes Verhalten, macht aber Sinn, da es Informationen über die Passkeys des Benutzers ohne dessen Zustimmung preisgeben könnte.

8.8.2.3 Keine transports-Eigenschaft gesetzt

Kein lokaler Passkey stimmt überein, daher haben Sie nur die Möglichkeit, einen Hardware-Sicherheitsschlüssel (z. B. YubiKey) / plattformübergreifenden Authenticator / Roaming-Authenticator zu verwenden.

8.8.2.4 Leere allowCredentials

Die Passkey-Authentifizierung ist nur über Windows Hello und Hardware-Sicherheitsschlüssel möglich.

8.9.1.1 transports: [internal, hybrid]

Wie erwartet, stimmt kein lokaler Passkey überein, daher wird vorgeschlagen, den QR-Code zu scannen und den Passkey auf einem anderen Gerät zu verwenden (da das System weiß, dass für diesen Benutzer ein Passkey existiert).

8.9.1.2 transports: [internal]

Verwirrenderweise werden Sie aufgefordert, Ihren Windows Hello-PIN-Code (oder Fingerabdruck / Gesichtsscan, falls auf dem Gerät eingerichtet) einzugeben, obwohl wir die Credential ID geändert haben (es sollte also eigentlich die Anmeldeinformation nicht finden, da sie nicht in der allowCredentials-Eigenschaft angegeben ist). Nach der Eingabe des Windows Hello-PIN-Codes wird jedoch ein Fehler ausgegeben: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Aus Benutzersicht ist dies ein ziemlich verwirrendes Verhalten, macht aber Sinn, da es Informationen über die Passkeys des Benutzers ohne dessen Zustimmung preisgeben könnte.

8.9.1.3 Keine transports-Eigenschaft gesetzt

Kein lokaler Passkey stimmt überein, daher wird vorgeschlagen, den QR-Code zu scannen oder einen Hardware-Sicherheitsschlüssel (z. B. YubiKey) / plattformübergreifenden Authenticator / Roaming-Authenticator zu verwenden.

8.9.1.4 Leere allowCredentials

Wie erwartet sind alle Formen der Passkey-Authentifizierung erlaubt: über Windows Hello, über QR-Code und über Hardware-Sicherheitsschlüssel. Aus irgendeinem Grund werden bekannte Geräte nicht angezeigt.

8.9.2.1 transports: [internal, hybrid]

Dies ist eine wirklich verwirrende Meldung für Benutzer, da nicht explizit angegeben wird, was sie tun und wie sie sich authentifizieren sollen. Die einzige Option, die sie haben, ist, auf „Abbrechen“ zu klicken, was dieses Szenario zu einer Sackgasse macht.

8.9.2.2 transports: [internal]

Dieses Verhalten ist dasselbe wie im Fall, dass Bluetooth aktiviert ist. Es ist sehr verwirrend, dass der Benutzer aufgefordert wird, den Windows Hello-PIN-Code (oder Fingerabdruck / Gesichtsscan, falls auf dem Gerät eingerichtet) einzugeben, obwohl wir die Credential ID geändert haben (es sollte also eigentlich die Anmeldeinformation nicht finden, da sie nicht in der allowCredentials-Eigenschaft angegeben ist). Nach der Eingabe des Windows Hello-PIN-Codes wird jedoch ein Fehler ausgegeben: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Aus Benutzersicht ist dies ein ziemlich verwirrendes Verhalten, macht aber Sinn, da es Informationen über die Passkeys des Benutzers ohne dessen Zustimmung preisgeben könnte.

8.9.2.3 Keine transports-Eigenschaft gesetzt

Kein lokaler Passkey stimmt überein, daher haben Sie nur die Möglichkeit, einen Hardware-Sicherheitsschlüssel (z. B. YubiKey) / plattformübergreifenden Authenticator / Roaming-Authenticator zu verwenden.

8.9.2.4 Leere allowCredentials

Die Passkey-Authentifizierung ist nur über Windows Hello und Hardware-Sicherheitsschlüssel möglich.

8.10.1.1 transports: [internal, hybrid]

Wie erwartet, stimmt kein lokaler Passkey überein, daher wird vorgeschlagen, den QR-Code zu scannen und den Passkey auf einem anderen Gerät zu verwenden (da das System weiß, dass für diesen Benutzer ein Passkey existiert).

8.10.1.2 transports: [internal]

Verwirrenderweise werden Sie aufgefordert, Ihren Windows Hello-PIN-Code (oder Fingerabdruck / Gesichtsscan, falls auf dem Gerät eingerichtet) einzugeben, obwohl wir die Credential ID geändert haben (es sollte also eigentlich die Anmeldeinformation nicht finden, da sie nicht in der allowCredentials-Eigenschaft angegeben ist). Nach der Eingabe des Windows Hello-PIN-Codes wird jedoch ein Fehler ausgegeben: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Aus Benutzersicht ist dies ein ziemlich verwirrendes Verhalten, macht aber Sinn, da es Informationen über die Passkeys des Benutzers ohne dessen Zustimmung preisgeben könnte.

8.10.1.3 Keine transports-Eigenschaft gesetzt

Kein lokaler Passkey stimmt überein, daher wird vorgeschlagen, den QR-Code zu scannen oder einen Hardware-Sicherheitsschlüssel (z. B. YubiKey) / plattformübergreifenden Authenticator / Roaming-Authenticator zu verwenden.

8.10.1.4 Leere allowCredentials

Wie erwartet sind alle Formen der Passkey-Authentifizierung erlaubt: über Windows Hello, über QR-Code und über Hardware-Sicherheitsschlüssel. Aus irgendeinem Grund werden bekannte Geräte nicht angezeigt.

8.10.2.1 transports: [internal, hybrid]

Dies ist eine wirklich verwirrende Meldung für Benutzer, da nicht explizit angegeben wird, was sie tun und wie sie sich authentifizieren sollen. Die einzige Option, die sie haben, ist, auf „Abbrechen“ zu klicken, was dieses Szenario zu einer Sackgasse macht. Aus irgendeinem Grund werden Teile des Windows-Sicherheitsmodals auch auf Deutsch angezeigt (eine zweite auf diesem Gerät installierte Sprache).

8.10.2.2 transports: [internal]

Dieses Verhalten ist dasselbe wie im Fall, dass Bluetooth aktiviert ist. Es ist sehr verwirrend, dass der Benutzer aufgefordert wird, den Windows Hello-PIN-Code (oder Fingerabdruck / Gesichtsscan, falls auf dem Gerät eingerichtet) einzugeben, obwohl wir die Credential ID geändert haben (es sollte also eigentlich die Anmeldeinformation nicht finden, da sie nicht in der allowCredentials-Eigenschaft angegeben ist). Nach der Eingabe des Windows Hello-PIN-Codes wird jedoch ein Fehler ausgegeben: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Aus Benutzersicht ist dies ein ziemlich verwirrendes Verhalten, macht aber Sinn, da es Informationen über die Passkeys des Benutzers ohne dessen Zustimmung preisgeben könnte.

8.10.2.3 Keine transports-Eigenschaft gesetzt

Kein lokaler Passkey stimmt überein, daher haben Sie nur die Möglichkeit, einen Hardware-Sicherheitsschlüssel (z. B. YubiKey) / plattformübergreifenden Authenticator / Roaming-Authenticator zu verwenden.

8.10.2.4 Leere allowCredentials

Die Passkey-Authentifizierung ist nur über Windows Hello und Hardware-Sicherheitsschlüssel möglich.

8.11.1.1 transports: [internal, hybrid]

Wie erwartet, stimmt kein lokaler Passkey überein, daher wird vorgeschlagen, den QR-Code zu scannen und den Passkey auf einem anderen Gerät zu verwenden (da das System weiß, dass für diesen Benutzer ein Passkey existiert).

8.11.1.2 transports: [internal]

Verwirrenderweise werden Sie aufgefordert, Ihren Windows Hello-PIN-Code (oder Fingerabdruck / Gesichtsscan, falls auf dem Gerät eingerichtet) einzugeben, obwohl wir die Credential ID geändert haben (es sollte also eigentlich die Anmeldeinformation nicht finden, da sie nicht in der allowCredentials-Eigenschaft angegeben ist). Nach der Eingabe des Windows Hello-PIN-Codes wird jedoch ein Fehler ausgegeben: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Aus Benutzersicht ist dies ein ziemlich verwirrendes Verhalten, macht aber Sinn, da es Informationen über die Passkeys des Benutzers ohne dessen Zustimmung preisgeben könnte.

8.11.1.3 Keine transports-Eigenschaft gesetzt

Kein lokaler Passkey stimmt überein, daher wird vorgeschlagen, den QR-Code zu scannen oder einen Hardware-Sicherheitsschlüssel (z. B. YubiKey) / plattformübergreifenden Authenticator / Roaming-Authenticator zu verwenden.

8.11.1.4 Leere allowCredentials

Wie erwartet sind alle Formen der Passkey-Authentifizierung erlaubt: über Windows Hello, über QR-Code und über Hardware-Sicherheitsschlüssel. Aus irgendeinem Grund werden bekannte Geräte nicht angezeigt.

8.11.2.1 transports: [internal, hybrid]

Dies ist eine wirklich verwirrende Meldung für Benutzer, da nicht explizit angegeben wird, was sie tun und wie sie sich authentifizieren sollen. Die einzige Option, die sie haben, ist, auf „Abbrechen“ zu klicken, was dieses Szenario zu einer Sackgasse macht.

8.11.2.2 transports: [internal]

Dieses Verhalten ist dasselbe wie im Fall, dass Bluetooth aktiviert ist. Es ist sehr verwirrend, dass der Benutzer aufgefordert wird, den Windows Hello-PIN-Code (oder Fingerabdruck / Gesichtsscan, falls auf dem Gerät eingerichtet) einzugeben, obwohl wir die Credential ID geändert haben (es sollte also eigentlich die Anmeldeinformation nicht finden, da sie nicht in der allowCredentials-Eigenschaft angegeben ist). Nach der Eingabe des Windows Hello-PIN-Codes wird jedoch ein Fehler ausgegeben: "NotAllowedError: The operation either timed out or was not allowed. See: https://www.w3.org/TR/webauthn-2/#sctn-privacy-considerations- client." Aus Benutzersicht ist dies ein ziemlich verwirrendes Verhalten, macht aber Sinn, da es Informationen über die Passkeys des Benutzers ohne dessen Zustimmung preisgeben könnte.

8.11.2.3 Keine transports-Eigenschaft gesetzt

Kein lokaler Passkey stimmt überein, daher haben Sie nur die Möglichkeit, einen Hardware-Sicherheitsschlüssel (z. B. YubiKey) / plattformübergreifenden Authenticator / Roaming-Authenticator zu verwenden.

8.11.2.4 Leere allowCredentials

Die Passkey-Authentifizierung ist nur über Windows Hello und Hardware-Sicherheitsschlüssel möglich.

• Verwenden Sie Bibliotheken und Frameworks, die einige der Komplexitäten der reinen WebAuthn-API abstrahieren.
• Berücksichtigen Sie von Anfang an plattformübergreifende Authentifizierungsszenarien, um sicherzustellen, dass eine breite Benutzerbasis von Ihrer Passkey-Implementierung profitieren kann. Abhängig von Ihren Designentscheidungen können Sie in diesen Szenarien auch alternative Anmeldemethoden anbieten.
• Entwickeln Sie Fallback-Mechanismen für Szenarien, in denen die plattformübergreifende Passkey-Authentifizierung (Hybrid Transport) aufgrund von Gerätebeschränkungen möglicherweise nicht möglich ist.
• Die größte Designentscheidung besteht darin, zu entscheiden, ob Sie die plattformübergreifende Passkey-Authentifizierung über QR-Code / Bluetooth (Hybrid Transport) fördern und zu einer prominenten Methode für die Passkey-Authentifizierung machen oder Hinweise verwenden möchten, um sie nicht aktiv zu bewerben. Im letzteren Fall wird immer versucht, sofort die intern gespeicherten Passkeys zu verwenden, und nur wenn kein interner Passkey gefunden wird, wird ein QR-Code für die plattformübergreifende Authentifizierung (Hybrid Transport) angezeigt. Dies muss in Ihren WebAuthn-Serveroptionen in den Eigenschaften excludeCredentials und allowCredentials definiert werden. In der excludeCredentials-Eigenschaft Ihres WebAuthn-Servers können Sie Transportinformationen über bereits erstellte Anmeldeinformationen sehen. In der allowCredentials-Eigenschaft können Sie das Verhalten im Anmeldeprozess festlegen (siehe Tests oben).
• Darüber hinaus können Sie die plattformübergreifende Passkey-Authentifizierung (Hybrid Transport) nicht vollständig verhindern (siehe die Tests oben mit transports: [internal]), daher müssen Sie darauf vorbereitet sein, dass Ihre Benutzer diese Methode finden und Fragen haben werden. Das Auftreten dieser plattformübergreifenden Authentifizierung (Hybrid Transport) wird insbesondere dann vorkommen, wenn Benutzer beginnen, Passkeys lokal zu löschen.

• Erstellen Sie umfassende Anleitungen und Tutorials, die Benutzer durch den Prozess der plattformübergreifenden Passkey-Authentifizierung (Hybrid Transport) führen.
• Verwenden Sie In-App-Tooltips und kontextbezogene Hilfeabschnitte, um Benutzer bei ihrer ersten Erfahrung mit der plattformübergreifenden Passkey-Authentifizierung (Hybrid Transport) zu leiten.
• Stellen Sie FAQs und Abschnitte zur Fehlerbehebung auf Ihrer Website oder innerhalb der Anwendung bereit.

• Implementieren Sie zeitlich begrenzte Sitzungen für Passkey-Anmeldungen über QR-Code oder Bluetooth, um sicherzustellen, dass der Zugriff nur vorübergehend und sicher ist.
• Stellen Sie sicher, dass die plattformübergreifende Passkey-Authentifizierung (Hybrid Transport) keine bestehenden Sicherheitsprotokolle untergräbt und die Integrität der Benutzerdaten gewahrt bleibt.
• Berücksichtigen Sie die Datenschutzimplikationen und stellen Sie sicher, dass jeder temporäre Zugriff, der über die plattformübergreifende Passkey-Authentifizierung (Hybrid Transport) gewährt wird, gemäß den besten Sicherheitspraktiken protokolliert und überwacht wird.

Die plattformübergreifende Passkey-Authentifizierung über QR-Code / Bluetooth (Hybrid Transport) bietet ein Gleichgewicht zwischen Sicherheit und UX. Es ist jedoch ein völlig neuer Prozess für die meisten Benutzer und könnte viele verwirrende Situationen verursachen, daher müssen Sie sorgfältig überlegen, ob Sie ihn fördern möchten.

Wir hoffen, dass wir etwas Licht in das Thema der plattformübergreifenden Passkey-Authentifizierung (Hybrid Transport) über QR-Code / Bluetooth bringen, erklären konnten, wie man die Dinge einrichtet und wie das Verhalten auf verschiedenen Geräte-/Browser-Kombinationen aussieht. Wenn Sie Fragen haben, können Sie uns gerne über unsere Passkeys-Community kontaktieren oder unseren Passkeys-Substack abonnieren. Lassen Sie uns das Internet zu einem sichereren Ort machen, indem wir Passkeys verbreiten.