WebAuthn Resident Keys: Discoverable Credentials als Passkeys

Passkeys und das zugrunde liegende WebAuthn-Protokoll revolutionieren die Welt der Authentifizierung. Einen WebAuthn-Server richtig einzurichten, kann jedoch eine knifflige Angelegenheit sein. Fehlkonfigurationen können nicht nur Sicherheitslücken schaffen, sondern auch bestehende Passkeys unbrauchbar machen, wenn man später Änderungen vornehmen muss. Dieser Blogbeitrag soll dabei helfen, die oft komplexen WebAuthn-Spezifikationen besser zu verstehen und Ratschläge geben, welche Einstellungen für den jeweiligen Anwendungsfall am besten geeignet sind.

WebAuthn arbeitet mit drei zentralen Akteuren:

• Relying Party (RP): Das ist der Web-Service, der einen User authentifizieren möchte. Er sendet Challenges an den Client, überprüft die Antworten und verwaltet den Public Key eines Passkeys.
• Authenticators: Das sind Geräte, die den Besitz eines Credentials nachweisen können. Beispiele sind Smartphones, Laptops oder Security Keys (z. B. YubiKeys). Authenticators können plattformspezifisch sein (wie Windows Hello oder Apples Touch ID / Face ID) oder plattformübergreifend (wie Security Keys, z. B. YubiKeys).
• Clients: Typischerweise sind das Webbrowser oder native Apps, die als Vermittler zwischen dem RP und dem Authenticator agieren. Sie erleichtern die Kommunikation und stellen sicher, dass die Daten korrekt und sicher fließen.

Want to try passkeys yourself in a passkeys demo?

Try Passkeys

Im Folgenden beschreiben wir den allgemeinen Datenfluss während eines Authentifizierungsprozesses (sowohl bei der Registrierung als auch beim Login).

1. Initiierung durch den Client: Der Prozess beginnt auf der Client-Seite, normalerweise wenn ein User versucht, sich einzuloggen oder zu registrieren. Zum Beispiel klickt er auf einen „Login mit WebAuthn“-Button, und der Client sendet eine Anfrage für eine Challenge an den RP.
2. Anfrage des RP: Der RP sendet dann eine Challenge an den Client zurück. Diese Challenge ist ein zufällig generierter Wert, der die Authentizität der nachfolgenden Antwort sicherstellt.
3. Client zum Authenticator: Bei der Registrierung fordert der Client den Authenticator auf, einen neuen Passkey zu erstellen, indem er das entsprechende Public-Private-Schlüsselpaar erzeugt. Beim Login fordert der Client den Authenticator auf, die Challenge zu signieren. Dies geschieht mit dem Private Key auf dem Authenticator, der zu einem zuvor beim RP gespeicherten Public Key gehört.
4. Antwort des Authenticators: Bei der Registrierung sendet der Authenticator den Public Key an den Client zurück. Beim Login signiert der Authenticator die Challenge und sendet diese signierte Assertion an den Client zurück.
5. Client zum RP: Der Client leitet diesen neuen Public Key bzw. die signierte Assertion an den RP weiter.
6. Verifizierung durch den RP: Der RP speichert den Public Key bzw. verifiziert die signierte Assertion mithilfe des gespeicherten Public Keys. Wenn sie gültig ist, ist die Authentifizierung erfolgreich.

Ben Gould

Head of Engineering

I’ve built hundreds of integrations in my time, including quite a few with identity providers and I’ve never been so impressed with a developer experience as I have been with Corbado.

10,000+ devs trust Corbado & make the Internet safer with passkeys. Got questions? We’ve written 150+ blog posts on passkeys.

Join Passkeys Community

Der oben beschriebene allgemeine Prozessablauf beschreibt die Registrierungs- und Login-Prozesse von WebAuthn. Passkeys bauen auf WebAuthn auf. Ursprünglich wurde der Begriff Passkeys als einprägsamerer und weniger technischer Begriff für WebAuthn verwendet, der dasselbe beschreibt. Darüber hinaus bieten Passkeys mehr Funktionen im Vergleich zu Standard-WebAuthn, z. B. die Möglichkeit, Passkeys über Cloud-Konten oder Passwort-Manager zu synchronisieren.

Um die folgenden Abschnitte besser zu verstehen, definieren wir einige wichtige Begriffe im WebAuthn-Protokoll, um ein gemeinsames Verständnis zu schaffen.

• Credential ID: Die Credential ID ist ein eindeutiger Identifikator, der einem bestimmten Public-Key-Credential zugewiesen wird, das von einem Authenticator generiert wurde. Sie ermöglicht es Relying Parties (RPs), das richtige PublicKeyCredential für Authentifizierungsprozesse zu identifizieren und auszuwählen.
• PublicKeyCredential: Dies ist die primäre Datenstruktur, die von der WebAuthn-API des Browsers oder der nativen App zurückgegeben wird. Sie umfasst sowohl die Attestation-Daten bei der Registrierung als auch die Assertion-Daten beim Login. Im Wesentlichen enthält sie die Daten, die der RP zur Überprüfung des Prozesses benötigt.
• Attestation: Die Attestation im WebAuthn-Kontext dient als Nachweis für die Herkunft und Integrität des Authenticators. Bei der Registrierung ist es eine Art des Authenticators zu sagen: „Ich habe das Credential des Users sicher registriert, und hier ist eine Erklärung, mit der du das überprüfen kannst.“ Die Relying Party kann dann überprüfen, ob die Signatur von einem bestimmten, erlaubten Authenticator stammt (z. B. YubiKey). Nicht alle Passkey-Authenticators antworten mit einer solchen Attestation; manche senden einfach keine nützlichen Daten zurück (siehe hier die Liste der Passkey-Authenticators). Weitere AAGUIDs (Authenticator Attestation GUIDs), die mehr Authenticators (hauptsächlich Security Keys, z. B. YubiKeys) identifizieren, finden sich im FIDO Alliance Metadata Service.
• Assertion: Nach dem Registrierungsprozess, wenn ein User versucht, sich einzuloggen, erzeugt der Authenticator eine Assertion. Die Assertion ist im Grunde das PublicKeyCredential plus die signierte Challenge. Diese Assertion beweist, dass der User den Private Key besitzt, der mit dem registrierten Public Key verknüpft ist, ohne den eigentlichen Private Key preiszugeben. Es ist die Art des Authenticators zu sagen: „Das ist der echte User, und ich kann für ihn bürgen.“

Subscribe to our Passkeys Substack for the latest news.

Subscribe

Resident Keys (RKs) und Non-Resident Keys (NRKs) sind zwei Arten von kryptografischen Schlüsseln, die im WebAuthn-Protokoll verwendet werden. Sie unterscheiden sich hauptsächlich in ihrem Speicherort und ihrem Abrufmechanismus.

Definition:

Resident Keys werden direkt auf dem Authenticator selbst gespeichert. Dies kann ein Security Key (z. B. YubiKey), eine Secure Enclave einer Plattform (z. B. die Secure Enclave des iPhones) oder ein Trusted Platform Module (TPM) auf einem Laptop sein. Die Conditional UI (Passkey Autofill) funktioniert nur mit Resident Keys, und die WebAuthn-Arbeitsgruppe verlangt derzeit, dass Resident Keys als Passkey betrachtet werden.

Im folgenden Screenshot sehen Sie eine Liste aller Resident Keys (Credential ID, rpID, Username, Anzeigename), die auf einem YubiKey gespeichert sind. Non-Resident Keys sind nicht in der Liste, da sie nicht auf dem Authenticator gespeichert sind:

Login-Ablauf:

Quelle: William Brown

Während des Login-Prozesses sendet die Relying Party eine Anfrage ohne Angabe von Credentials an den Client (Browser), der den Authenticator (hier in der Grafik: Security Key) abfragt. Der Authenticator findet alle Resident Keys für die entsprechende Relying Party, und der Client (Browser) wählt den gewünschten Resident Key aus. Dieser Resident Key wird verwendet, um die Challenge zu signieren. Die Signatur wird vom Authenticator über den Client an die Relying Party gesendet.

Vorteile:

1. Optimierte User Experience: Einer der größten Vorteile von Resident Keys ist, dass der Authenticator den User Handle (z. B. E-Mail, Telefonnummer, Benutzername) speichert und somit den User Handle (z. B. E-Mail, Telefonnummer, Benutzername) für den Login vorausfüllen kann. User müssen sich keine User Handles (z. B. E-Mail, Telefonnummer, Benutzername) merken oder eingeben, was den Login-Prozess optimiert, insbesondere auf Geräten mit biometrischen Fähigkeiten. Dies kann auch automatisch mit Conditional UI geschehen.
2. Gerätespezifische Authentifizierung: Resident Keys können eine zusätzliche Sicherheitsebene bieten, indem sie die Authentifizierung an ein bestimmtes Gerät binden. Dies kann besonders nützlich sein für Dienste, die sicherstellen möchten, dass sich User von vertrauenswürdigen Geräten aus einloggen.
3. Conditional UI (Passkey Autofill): Conditional UI funktioniert nur mit Resident Keys und bietet das nahtloseste Login-Erlebnis (siehe unten für Details).

Nachteile:

1. Speicherbegrenzung: Einige Authenticators haben eine begrenzte Speicherkapazität. Insbesondere bei Security Keys (z. B. YubiKeys) gibt es oft ein Limit für die Anzahl der Resident Keys, die sie speichern können (die meisten haben ein Limit zwischen 8 und ca. 100 Resident Keys). Sobald dieses Limit erreicht ist, müssen möglicherweise ältere Schlüssel gelöscht werden, um Platz für neue zu schaffen, oder der User muss einen anderen Authenticator verwenden.
2. Verlust des Authenticators: Wenn der Authenticator, z. B. ein Security Key (z. B. YubiKey) oder ein Smartphone, verloren geht oder beschädigt wird, gehen alle Resident Keys auf diesem Gerät verloren. Dies könnte User von mehreren Diensten aussperren, bis sie ihre Konten neu registrieren oder wiederherstellen. Die Synchronisierung von Schlüsseln über ein Cloud-Konto (z. B. iCloud Keychain, Google Password Manager) oder einen modernen Password Manager (z. B. 1Password oder Dashlane) verhindert diesen Verlust.
3. Sicherheitsbedenken: Wenn ein Authenticator mit Resident Keys gestohlen wird, könnte ein Angreifer versuchen, die Schlüssel zu extrahieren. Obwohl moderne Authenticators robuste Sicherheitsmechanismen haben, um die Extraktion zu verhindern (z. B. schützt der User das Gerät mit einer starken PIN, einem Passcode oder einer Geste), besteht das Risiko, wenn auch minimal, weiterhin.

Anwendungsfälle: Ideal für Geräte, auf denen sich der User häufig authentifiziert, wie persönliche Smartphones oder Laptops.

Want to find out how many people use passkeys?

View Adoption Data

Definition:

Non-Resident Keys werden im Gegensatz dazu nicht auf dem Authenticator gespeichert. Stattdessen generiert der Authenticator ein neues Schlüsselpaar (basierend auf seinem intern geschützten Master-Key) und sendet den Public Key dieses neuen Schlüsselpaars zusammen mit der Credential ID (die einen Seed enthält) bei der Registrierung an den Server (Relying Party). Der Server verknüpft dann diesen Public Key mit dem Konto des Users. Für nachfolgende Authentifizierungen leitet der Authenticator den Private Key neu ab, indem er die Credential ID empfängt, den Seed extrahiert und ihn mit dem Master-Key kombiniert. Da der Schlüssel nur vorübergehend im geschützten Speicher des Authenticators verfügbar ist, wird er in der kryptografischen Sprache manchmal als ephemerer Schlüssel bezeichnet.

Login-Ablauf:

Quelle: William Brown

Während des Login-Prozesses muss die Relying Party zuerst identifizieren, welcher User eine Authentifizierung anfordert (z. B. indem nach einem User Handle wie E-Mail, Telefonnummer oder Benutzername gefragt wird) und sendet dann die Credential IDs, die ihr für den anfragenden User bekannt sind, an den Client (Browser). Der Client leitet sie an den Authenticator (hier: Security Key) weiter. Der Authenticator verwendet die Credential ID zusammen mit dem Master-Key des Authenticators, um den temporären Private Key abzuleiten, signiert die Challenge mit dem generierten Schlüssel und gibt ihn an den Client (hier: Browser) zurück, der ihn an die Relying Party weiterleitet. Non-Resident Keys wurden ursprünglich als zweiter Faktor vor der Einführung von Passkeys verwendet. Daher war die Identifizierung des Users zuerst Teil des regulären Login-Prozesses.

Vorteile:

1. Skalierbarkeit: Da Non-Resident Keys nicht auf dem Authenticator gespeichert werden, können User eine nahezu unbegrenzte Anzahl von Non-Resident Keys haben, die mit verschiedenen Diensten verknüpft sind. Dies ist besonders vorteilhaft für User, die Konten auf zahlreichen Plattformen haben.
2. Roaming-Fähigkeit: Non-Resident Keys sind ideal für Roaming-Authenticators wie Security Keys (z. B. YubiKey). Ein User kann denselben Security Key (z. B. YubiKey) verwenden, um sich auf mehreren Geräten und Plattformen zu authentifizieren, was eine konsistente Erfahrung bietet.
3. Reduzierte Abhängigkeit vom Authenticator-Speicher: Bei geeigneten WebAuthn-Servereinstellungen muss man sich keine Sorgen über die Speicherbeschränkungen des Authenticators machen. Dies kann besonders vorteilhaft für Authenticators mit geringem Speicherplatz sein, wie Security Keys (z. B. YubiKeys).

Nachteile:

1. Schlechtere UX, da User Handle erforderlich ist: Der größte Nachteil von Non-Resident Keys ist, dass der User Handle (z. B. E-Mail, Telefonnummer, Benutzername) vom User angegeben werden muss, was ein Vorausfüllen des Benutzernamens über Conditional UI unmöglich macht. Dieser User Handle muss mit der Credential ID verknüpft sein, die zur Berechnung des ephemeren, schlüsselumwickelten Schlüssels benötigt wird.
2. Potenzial für Missmanagement: RPs müssen die Verknüpfungen zwischen Benutzerkonten und Public Keys verwalten und sichern. Schlechtes Management oder Sicherheitslücken könnten zu Sicherheitsproblemen führen.

Anwendungsfälle: Ideal für Roaming-Authenticators wie Security Keys (z. B. YubiKeys), die über mehrere Dienste oder Plattformen hinweg verwendet werden.

Stellen Sie sich vor, Sie haben einen Security Key (z. B. YubiKey) und registrieren ihn bei zwei Online-Diensten: Dienst A und Dienst B. Für Dienst A verwenden Sie einen Resident Key. Für Dienst B einen Non-Resident Key. Wenn Sie sich bei Dienst A authentifizieren, tippen Sie einfach auf Ihren Security Key (z. B. YubiKey), und Sie sind drin – ohne einen Benutzernamen angeben zu müssen. Bei Dienst B geben Sie zuerst Ihren Benutzernamen im Browser / in der nativen App ein. Der Dienst sendet dann die zugehörige Credential ID an Ihren Security Key (z. B. YubiKey), der dann den ephemeren Private Key für die Authentifizierung neu generiert.

Im Wesentlichen verbessern sowohl Resident- als auch Non-Resident-Keys die Sicherheit durch kryptografische Authentifizierung, aber ihre User Experience und Speichermechanismen unterscheiden sich und sind auf unterschiedliche Anwendungsfälle zugeschnitten.

Want to experiment with passkey flows? Try our Passkeys Debugger.

Try for Free

Conditional UI ist eine Meilenstein-Funktion von Passkeys / WebAuthn. Sie nimmt dem User noch mehr Last ab, da sich der User nicht nur kein Passwort mehr merken muss, sondern auch nicht mehr den User Handle (z. B. E-Mail, Telefonnummer, Benutzername), mit dem er sich bei einer Relying Party registriert hat. Besonders in Fällen, in denen die Dienste von Relying Parties nur gelegentlich genutzt werden, ist dies ein riesiger Schritt.

Dies funktioniert, weil der Relying-Party-Server, sobald die Login-Seite geöffnet wird, im Hintergrund eine Challenge an den Client sendet (erinnern Sie sich, es muss keine Credential ID in diesem Aufruf gesendet werden). Der Client nimmt diese Challenge und prüft, welche Passkeys auf diesem Authenticator zur Relying Party ID passen, und bietet die Auswahl über das Autofill-Menü an, wo der User den passenden Passkey auswählen kann.

Darüber hinaus erspart es dem User auch einen zusätzlichen Klick auf den Login-Button, denn sobald der Passkey aus dem Autofill-Menü ausgewählt ist, startet der Login-Prozess.

CTAP ist ein grundlegendes Protokoll im FIDO2-Standard, das die Kommunikationslücke zwischen Clients (wie Browsern) und Authenticators (wie Security Keys, z. B. YubiKeys, oder Smartphones) überbrückt. Um CTAP besser zu verstehen, werfen wir einen kurzen Blick auf die verschiedenen Protokollversionen, bevor wir die Auswirkungen auf Resident und Non-Resident Keys analysieren.

Die frühere Version, oft als Universal 2nd Factor (U2F) bezeichnet, wurde hauptsächlich für die Zwei-Faktor-Authentifizierung entwickelt. Bei U2F stellt der Server eine Challenge bereit, und der Authenticator gibt eine Antwort, die den Besitz des Private Keys beweist. U2F unterstützt jedoch keine Resident Keys, was bedeutet, dass immer eine serverseitige Abfrage erforderlich ist, um zu identifizieren, welcher Schlüssel für einen User verwendet werden soll, da dies Teil des Prozesses war, wenn nach einem zweiten Faktor gefragt wurde.

Als Nachfolger von U2F führte CTAP2 die Unterstützung für Resident Keys ein, was eine passwort- und benutzernamenlose Authentifizierung ermöglicht. Mit Resident Keys speichert der Authenticator den Benutzernamen und die Credential ID des Users (zusammen mit der Relying Party ID), sodass der Relying-Party-Server sie während der Authentifizierung nicht bereitstellen muss. Dies ist ein bedeutender Sprung zu einer nahtloseren UX.

CTAP2 bringt jedoch Herausforderungen mit sich. Ein bemerkenswertes Problem ist die Verwaltung von Resident Keys. Zum Beispiel erfordert das Löschen eines bestimmten Resident Keys in einem CTAP2.0-Gerät oft einen vollständigen Gerätereset (wodurch auch Ihr Master-Key zurückgesetzt wird, was bedeutet, dass alle Ihre Non-Resident Keys ebenfalls nicht mehr funktionieren). Das ist nicht benutzerfreundlich und kann in Szenarien, in denen mehrere Resident Keys auf einem einzigen Gerät gespeichert sind, problematisch sein. Das macht Resident Keys auf einem CTAP2.0-Gerät zu einer ernsthaften Verpflichtung. Man möchte den begrenzten Speicherplatz, den man oft hat, besonders auf Security Keys (z. B. YubiKeys), wirklich nicht versehentlich füllen.

CTAP2.1 ist eine nachfolgende Version von CTAP2, die zusätzliche Funktionen und Verbesserungen des Protokolls mit sich bringt. Einige wichtige Punkte zu CTAP 2.1 sind:

• Besseres Resident-Key-Management: CTAP 2.1 ermöglicht die individuelle Verwaltung, Aktualisierung und Löschung spezifischer Resident Keys von Ihrem Gerät.
• Enterprise Attestation: Diese Funktion gibt Unternehmen mehr Kontrolle über die von ihren Mitarbeitern verwendeten Schlüssel. Sie bietet eine Möglichkeit für Unternehmen zu überprüfen, ob die verwendeten Schlüssel vom Unternehmen ausgegeben wurden.
• Mehrfache Benutzererkennung: Einige Authenticators können mehrere User erkennen. CTAP 2.1 bietet eine Möglichkeit für diese Authenticators, anzuzeigen, welcher User erkannt wurde.
• Abwärtskompatibilität: CTAP 2.1 ist so konzipiert, dass es abwärtskompatibel mit CTAP2 ist, um sicherzustellen, dass Geräte und Plattformen, die die ältere Version unterstützen, weiterhin mit der neuen funktionieren können.

Nachdem wir uns Resident Keys, Non-Resident Keys und die verschiedenen CTAP-Versionen angesehen haben, analysieren wir nun die Seite der Relying Party und damit die WebAuthn-Serverseite genauer.

Die Flexibilität (aber auch die Komplexität) von WebAuthn ist größtenteils auf seine Servereinstellungen zurückzuführen, insbesondere innerhalb des authenticatorSelection-Objekts. Dieses Objekt leitet den Client bei der Auswahl des richtigen Authenticators für die Aufgabe.

{
    "rp": {
        "name": "corbado.com",
        "id": "corbado.com"
    },
    "user": {
        "id": "dGVzdefEyMjE",
        "name": "test-username",
        "displayName": "test-username"
    },
    "challenge": "mhanjsapJjCNaN_Ttasdfk1C0DymR-V_w_0UVOPsdfdfJG2ON_FK5-ODtqp33443tgqHzuuDjv-NUUmMAE4hg",
    "pubKeyCredParams": [
        {
            "type": "public-key",
            "alg": -7
        },
        {
            "type": "public-key",
            "alg": -257
        }
    ],
    "timeout": 60000,
    "excludeCredentials": [],
    "authenticatorSelection": {
        "authenticatorAttachment": "platform",
        "residentKey": "preferred",
        "requireResidentKey": false,
        "userVerification": "preferred"
    },
    "attestation": "none",
    "extensions": {
        "credProps": true
    }
}

Diese Serveroption gibt an, wie der Authenticator am Client-Gerät angebracht ist. Sie gibt Aufschluss darüber, wie der Authenticator mit dem Client kommuniziert:

Mögliche Werte

• Platform: Dies zeigt an, dass der Authenticator an die Plattform des Clients gebunden und daher nicht abnehmbar ist.
• Cross-platform: Dies zeigt an, dass der Authenticator nicht an die Plattform des Clients gebunden ist und auf mehreren Geräten verwendet werden kann.

Anwendungsfälle & Beispiele

• Platform: Beispiele sind ein Fingerabdruckscanner, der in einen Laptop eingebaut ist, oder ein Gesichtserkennungssystem auf einem Telefon, z. B. Face ID, Touch ID oder Windows Hello.
• Cross-platform: Beispiele sind USB-Security-Keys (z. B. YubiKeys), Bluetooth-Geräte oder NFC-Karten.

In der WebAuthn Level 1 Spezifikation hieß diese Serveroption requireResidentKey und konnte die booleschen Werte true (der Authenticator muss einen Resident Key erstellen) oder false (der Authenticator muss einen Non-Resident Key erstellen) annehmen. WebAuthn Level 2 ersetzte diese Serveroption durch die neue Serveroption residentKey:

Mögliche Werte

• Required: Der Authenticator muss einen Resident Key erstellen (falls nicht möglich, sollte die Operation fehlschlagen).
• Preferred: Der Authenticator sollte versuchen, einen Resident Key zu erstellen (falls nicht möglich, sollte er einen Non-Resident Key erstellen).
• Discouraged: Der Authenticator muss einen Non-Resident Key erstellen (falls nicht möglich, sollte die Operation fehlschlagen).

Anwendungsfälle & Beispiele

• Required: Ideal für Szenarien, in denen ein Login ohne Benutzernamen gewünscht ist oder in denen sich User nur von zuvor registrierten Geräten authentifizieren sollen (durch Hinzufügen einer zusätzlichen Sicherheitsebene, indem das Credential des Users an ein bestimmtes Gerät gebunden wird).
• Preferred: Geeignet für Szenarien, in denen der Web-Service die bestmögliche Login-UX bieten möchte (über Resident Keys), aber dennoch Non-Resident Keys unterstützen will, falls Resident Keys nicht möglich sind.
• Discouraged: Ein Dienst möchte Passkey-Authentifizierung anbieten und sicherstellen, dass User jeden Authenticator verwenden können, auch solche ohne Speicherkapazitäten, ohne das Credential an ein bestimmtes Gerät zu binden.

Die User Verification bezieht sich auf den Prozess, der sicherstellt, dass die Person, die mit dem Authenticator interagiert, der rechtmäßige Besitzer ist. Dies geschieht typischerweise durch die Anforderung einer spezifischen Authentifizierungsgeste wie der Eingabe einer PIN, der Bereitstellung eines Fingerabdrucks oder der Verwendung von Gesichtserkennung.

Manchmal wird auch die User Presence (UP) erwähnt oder ähnlich wie die User Verification verwendet, aber es gibt tatsächlich einige Unterschiede. Die User Presence bestätigt nur, dass jemand – irgendjemand – physisch anwesend ist und mit dem Gerät interagiert. Sie überprüft nicht die Identität dieser Person. Eine einfache Berührung eines Security Keys, ohne weitere Identitätsprüfungen, kann für die User Presence ausreichen. Für Passkeys / WebAuthn muss der User immer anwesend sein.

Mögliche Werte

• Required: Die Operation muss eine User Verification haben.
• Preferred: Die Operation sollte, wenn möglich, eine User Verification haben, kann aber auch ohne fortfahren.
• Discouraged: Die Operation sollte keine User Verification haben.

Anwendungsfälle & Beispiele

• Required: Ideal für Hochsicherheitsanwendungen wie Banking oder Gesundheitswesen, bei denen die Überprüfung der Identität des Users (z. B. durch Fingerabdruck oder PIN) entscheidend ist.
• Preferred: Nützlich für allgemeine Anwendungen, bei denen zusätzliche Sicherheit ein Bonus, aber nicht zwingend erforderlich ist.
• Discouraged: Geeignet für risikoarme Operationen oder Szenarien, in denen eine User Verification eine Unannehmlichkeit darstellen könnte.

Muster

• Authenticator Attachment: platform
• Resident Key: required
• User Verification: required

Beispiel: Eine Unternehmensanwendung möchte, dass sich Mitarbeiter ohne Passwörter auf ihren firmeneigenen Laptops mit eingebauten Fingerabdrucklesern anmelden. Das Credential wird auf dem Gerät gespeichert, und der User muss sich jedes Mal mit einem Fingerabdruck verifizieren.

Muster

• Authenticator Attachment: cross-platform
• Resident Key: required
• User Verification: required

Beispiel: Ein User registriert einen Security Key (z. B. YubiKey) für sein Online-Banking. Er kann diesen Schlüssel verwenden, um sich auf jedem Gerät zu authentifizieren, indem er den Security Key (z. B. YubiKey) bereitstellt, ohne einen Benutzernamen eingeben zu müssen.

Viele hardwarebasierte Security Keys (z. B. YubiKeys) haben inhärente Speicherbeschränkungen. Diese Begrenzung ist auf den physischen Speicher auf dem Gerät und die Designüberlegungen des Herstellers zurückzuführen.

Beispiel: Ein YubiKey hat möglicherweise nur Kapazität für 20 Resident Keys. Sobald dieses Limit erreicht ist, können keine zusätzlichen Resident Keys hinzugefügt werden, ohne bestehende zu löschen.

Lösung:

• Selektive Verwendung von Resident Keys: Anstatt Resident Keys für jeden User zu verwenden, sollten Sie sie für bestimmte Rollen oder Szenarien in Betracht ziehen. Priorisieren Sie beispielsweise Resident Keys für Admin-Rollen oder hochprivilegierte User, die eine erhöhte Sicherheit benötigen.
• Benutzeraufklärung: Informieren Sie die User über die Einschränkungen ihrer Security Keys (z. B. YubiKeys). Ermutigen Sie sie, auf Geräte umzusteigen, die unbegrenzt viele Resident Keys verwenden können, z. B. Laptops oder Smartphones.

Unterschiedliche Authenticators können Anfragen für Resident Keys unterschiedlich behandeln. Einige erstellen möglicherweise standardmäßig einen Resident Key, auch wenn dies nicht explizit angefordert wird, während andere eine explizite Anweisung benötigen.

Das inkonsistente Verhalten bei verschiedenen WebAuthn-Server-Optionen auf unterschiedlichen Plattformen ist ein großes Problem. Zum Beispiel erstellt iOS immer einen Resident Key, unabhängig von den übergebenen WebAuthn-Server-Optionen, während Android ein Opt-in erfordert (z. B. mit residentKey: preferred oder residentKey: required).

Neben dem Verhalten ist es noch schlimmer, dass man anhand der serverseitig gespeicherten Daten nicht mit 100%iger Sicherheit sagen kann, ob ein gespeichertes Credential ein Resident Key oder ein Non-Resident Key ist. Stattdessen kann man einige Prüfungen durchführen und es eingrenzen (siehe unten), muss aber immer noch hoffen, dass das Verhalten des Credentials der Annahme entspricht.

Der Grund dafür ist, dass es einen WebAuthn-Vorschlag gibt, Informationen über die Art des Credentials (Resident Key oder Non-Resident Key) in der Credential Properties Extension (clientExtensionResults.credProps.rk, was entweder true oder false ist) zu speichern. Die Bereitstellung dieser Informationen an den RP ist jedoch nicht garantiert, da alle WebAuthn-Erweiterungen optional sind, z. B. sendet iOS sie nicht (man weiß also nicht, ob es sich um einen Resident Key oder einen Non-Resident Key handelt).

Während unserer Recherche haben wir versucht, das Verhalten auf verschiedenen Plattformen und Authenticators (Windows 10, Windows 11, Android 7, Android 13, iOS17, macOS Ventura, YubiKey) mit zwei WebAuthn-Demo-Seiten zu testen, die mehr Details zu den erstellten Credentials liefern: https://webauthn.io und https://webauthntest.identitystandards.io/. Letztere bietet die Möglichkeit, mit der veralteten requireResidentKey-Eigenschaft (WebAuthn Level 1) zu arbeiten und sie sogar mit der residentKey-Eigenschaft (WebAuthn Level 2) zu kombinieren. Die Ergebnisse waren jedoch nicht zuverlässig (z. B. wurde für iOS ein Non-Resident Key angegeben, obwohl Conditional UI eindeutig funktionierte).

Das vertrauenswürdigste Prüfschema, das wir gefunden haben, ist das folgende:

1. Überprüfen Sie Ihre WebAuthn-Servereinstellungen für das Attribut „residentKey“
   1. Wenn „residentKey: required“ und ein Credential erfolgreich erstellt wird -> es ist ein Resident Key
   2. Wenn „residentKey: preferred“ oder „residentKey: discouraged“, dann weiter zur nächsten Prüfung
2. Wird die Erweiterung credProps.rk unterstützt und im Credential auf dem Server gespeichert?
   1. Wenn credProps.rk = true, ist das Credential ein Resident Key
   2. Wenn credProps.rk = false, ist das Credential ein Non-Resident Key
   3. Wenn credProps leer ist, ist der Typ des Credentials unbekannt

Wie Sie sehen, hilft dies, es einzugrenzen, aber die unbekannte Option bleibt bestehen, und man kann den Typ des Schlüssels nicht mit 100%iger Sicherheit bestimmen.

Dies deckt sich auch mit den Erkenntnissen von William Brown von SUSE in seinem großartigen Artikel, in dem er darlegt, wie Security Keys (z. B. YubiKeys) nutzlos werden könnten, wenn Resident Keys von Relying Parties verlangt werden (wir haben seine Tabelle erweitert):

In der Tabelle sehen Sie für verschiedene WebAuthn-Server-Resident-Key-Optionen, ob ein Resident Key erstellt wurde (true), ob ein Non-Resident Key erstellt wurde (false) oder etwas anderes passiert ist.

Lösung:

• Gründliches Testen: Testen Sie Ihre WebAuthn-Implementierung vor der Bereitstellung mit einer Reihe gängiger Authenticators, um deren Verhalten zu verstehen.
• Explizite Servereinstellungen: Seien Sie bei der Einrichtung Ihres WebAuthn-Servers explizit in Ihren Anforderungen. Wenn Sie nur Passkeys haben möchten, setzen Sie die Option residentKey auf required (beachten Sie, dass dies zu anderen Herausforderungen mit Authenticators mit begrenzter Resident-Key-Kapazität führen kann, siehe oben).

Wenn ein User das Speicherlimit auf seinem Security Key (z. B. YubiKey) erreicht, können Fehler auftreten oder er kann keine neuen Credentials registrieren. Dies kann zu Verwirrung und Frustration führen.

Lösung:

• Anmutige Fehlerbehandlung: Implementieren Sie klare Fehlermeldungen, die den User informieren, wenn sein Security Key (z. B. YubiKey) voll ist, und geben Sie Anleitungen zur Lösung des Problems.
• Geführte Arbeitsabläufe: Bieten Sie Schritt-für-Schritt-Anleitungen oder Tutorials an, wie User ihre Resident Keys verwalten können, um sicherzustellen, dass sie Probleme selbstständig lösen können.

9. Best Practices für Entwickler und Produktmanager

Wie Sie oben gesehen haben, können die von Ihnen gewählten WebAuthn-Servereinstellungen die User Experience und die Sicherheit Ihres Authentifizierungsprozesses erheblich beeinflussen. Es ist wichtig, die Nuancen dieser Einstellungen zu verstehen, um fundierte Entscheidungen zu treffen.

Resident vs. Non-Resident Keys: Wenn die Mehrheit Ihrer User hauptsächlich von persönlichen Geräten wie Smartphones oder Laptops auf Ihren Dienst zugreift, sind Resident Keys eine geeignete Wahl. Resident Keys werden auf dem Gerät selbst gespeichert und bieten eine nahtlose Authentifizierungserfahrung für User, die häufig dasselbe Gerät verwenden. Für User, die jedoch Security Keys (z. B. YubiKeys) verwenden, könnten Non-Resident Keys besser geeignet sein.

User Verification (UV) Einstellungen: Abhängig vom gewünschten Sicherheitsniveau können Sie entscheiden, wie streng der User Verification-Prozess sein soll. Wenn Sie eine hohe Sicherheit anstreben, ist die Anforderung einer PIN, eines Fingerabdrucks oder einer Gesichtserkennung (userVerification: preferred oder userVerification: required) ratsam.

Attestation und Vertrauenswürdigkeit: Die Attestation ermöglicht es Ihnen, die Herkunft und Integrität des Authenticators zu überprüfen. Entscheiden Sie, ob Sie allen Authenticators oder nur denen von bestimmten Herstellern vertrauen möchten. Dies kann entscheidend sein, wenn Sie mit sensiblen Daten umgehen und sicherstellen möchten, dass nur hochwertige, vertrauenswürdige Authenticators verwendet werden.

Fallback-Mechanismen: Haben Sie immer einen Fallback-Mechanismus parat. Wenn ein User seinen Authenticator verliert oder dieser nicht funktioniert, sollte er eine alternative Möglichkeit haben, auf sein Konto zuzugreifen. Dies könnte durch Backup-Codes, SMS-Verifizierung, E-Mail-Magic-Links oder andere Multi-Faktor-Authentifizierungs-Methoden geschehen.

Kontinuierliche Weiterbildung: Die Landschaft von Passkeys und WebAuthn entwickelt sich ständig weiter. Bleiben Sie über die neuesten Entwicklungen, Sicherheitslücken und Patches auf dem Laufenden. Ermutigen Sie Ihr Entwicklungsteam, an Workshops, Webinaren und Konferenzen zu Passkeys und WebAuthn teilzunehmen.

User-Onboarding und -Aufklärung: Wenn Sie die Passkey-Authentifizierung einführen, stellen Sie sicher, dass Ihre User deren Vorteile und Funktionsweise verstehen. Bieten Sie während des Registrierungsprozesses klare Anweisungen und stellen Sie Ressourcen (wie FAQs oder Video-Tutorials) zur Verfügung, um User bei der Einrichtung und Verwendung von Passkeys zu unterstützen.

Durch die Einhaltung dieser Best Practices können Entwickler und Produktmanager sicherstellen, dass sie die Passkey-Authentifizierung effektiv implementieren und dabei sowohl Sicherheit als auch User Experience in Einklang bringen.

Wenn Sie Passkeys für die breite Masse in Ihrer Website oder App implementieren möchten und keine Security Keys (z. B. YubiKeys) unterstützen müssen, da die meisten Ihrer User einfach ihr Smartphone oder ihren Laptop verwenden werden, empfehlen wir die folgenden Einstellungen.

• authenticator: platform
• residentKey: required
• userVerification: required

Vorteile:

• Da alle erstellten Schlüssel Resident Keys sind, ermöglicht das Setup die Conditional UI, was den Login für Ihre User noch nahtloser macht, da sie sich keinen Benutzernamen merken müssen.
• Alle modernen Geräte von Apple, Google und Microsoft werden unterstützt und verwenden Passkeys.

Die Servereinstellungen von WebAuthn sind zwar komplex, bieten aber ein robustes und flexibles Framework für die Authentifizierung. Die Beherrschung dieser Einstellungen ist entscheidend, da es nicht nur um die Implementierung eines neuen Standards geht, sondern darum, die Sicherheit und Effizienz der User-Authentifizierung grundlegend zu verbessern.

Im Wesentlichen ist das Verständnis der Servereinstellungen von WebAuthn eine Investition in den Aufbau sichererer, effizienterer und zukunftsorientierter Anwendungen. Da sich die digitale Landschaft weiterentwickelt, wird es unerlässlich sein, sich mit solchen Technologien gut auszukennen. Um auf dem Laufenden zu bleiben, treten Sie unserer Passkeys-Community bei oder abonnieren Sie unseren Newsletter unten.