Passkeys und passwortlose Authentifizierung

Was sind Passkeys und passwortlose Authentifizierung?

Passkeys sind FIDO-Anmeldedaten auf Basis asymmetrischer Schlüsselpaare; passwortlose Authentifizierung ist der weitere Oberbegriff, zu dem Passkeys als eine mögliche Methode gehören.

Technische Einordnung: Bei einem Passkey speichert der Dienst den öffentlichen Schlüssel. Die Anmeldung erfolgt über eine kryptografisch signierte Antwort, die mit dem zugehörigen privaten Schlüssel erzeugt und lokal durch eine Autorisierungsgeste freigegeben wird. Ein Passwort wird dabei nicht als gemeinsames Geheimnis an den Dienst übermittelt.

Wofür ist WebAuthn zuständig?

WebAuthn standardisiert für Webanwendungen die Erstellung und Nutzung starker Public-Key-Anmeldedaten, die an eine Relying Party beziehungsweise deren RP ID gebunden sind. Der aufrufende Web-Kontext muss sicher sein; dazu gehört insbesondere ein fehlerfrei aufgebauter sicherer Transport wie TLS. Die Relying Party entscheidet in ihrer Implementierung, ob sie Passkeys anbietet und welche Authenticatoren sie zulässt.

Wie läuft eine Passkey-Anmeldung ab?

Auch bei der Registrierung eines neuen Credentials muss die Relying Party die Registrierungszeremonie vollständig nach den dafür geltenden WebAuthn-Prüfschritten validieren, bevor sie das Credential und den öffentlichen Schlüssel dem Konto zuordnet. Diese Registrierungsprüfung ist von der späteren Prüfung einer Authentication Assertion zu unterscheiden.

Für die Anmeldung benötigt die Relying Party die zuvor registrierte Zuordnung der Anmeldedaten und den dazugehörigen öffentlichen Schlüssel. Sie startet eine WebAuthn-Zeremonie mit einer Challenge. Der Authenticator erzeugt nach der Autorisierungsgeste eine signierte Assertion. Bevor der Dienst das Konto als authentifiziert behandelt, muss er die Zeremonie vollständig prüfen, insbesondere Challenge, Kontozuordnung, Origin beziehungsweise RP-Bezug und Signatur.

Wann ist Nutzerverifikation erforderlich?

Nutzerpräsenz und Nutzerverifikation sind verschiedene Merkmale. Nutzerverifikation ist nur zwingend, wenn die Relying Party sie verlangt. Dann muss die Freigabegeste die geforderte Verifikation enthalten; wird sie verweigert oder schlägt sie fehl, endet die Operation mit einem Fehler. PIN oder Biometrie sind deshalb keine universelle Voraussetzung jeder Passkey-Anmeldung.

Warum kann WebAuthn phishing-resistent sein?

Technische Einordnung: Die Phishing-Resistenz einer WebAuthn-Public-Key-Anmeldung beruht auf der Bindung an Origin und RP ID sowie auf der kryptografisch signierten Assertion. Sie setzt voraus, dass der Dienst RP-Bezug, Origin und Signatur korrekt validiert. Der bloße Verzicht auf ein Passwort erzeugt diese Eigenschaft nicht automatisch.

Welche Passkey-Varianten gibt es?

Synchronisierte Multi-Device-Credentials können über den Dienst eines Passkey-Anbieters auf mehreren Geräten des Nutzers verfügbar sein. Gerätegebundene Single-Device-Credentials verlassen dagegen das einzelne Gerät nicht. Beide Varianten haben unterschiedliche Verlust- und Wiederherstellungseigenschaften und dürfen in der Risikobewertung nicht gleichbehandelt werden.

Für den Verlust gerätegebundener Zugangsdaten empfiehlt WebAuthn zusätzliche Authenticatoren und/oder einen Kontowiederherstellungsprozess. Die konkrete Wiederherstellung hängt außerdem von den Verfahren des Dienstes, des Geräts und des Passkey-Anbieters ab.

Gelten Einführungsfristen oder Schwellenwerte?

Die hier ausgewerteten allgemeinen WebAuthn- und FIDO-Spezifikationen bestimmen weder eine allgemeine Einführungsfrist noch einen allgemeinen numerischen Schwellenwert für Passkeys. Ein von der Relying Party gesetzter Request-Timeout ist nur ein technischer Parameter einer einzelnen WebAuthn-Zeremonie und keine Einführungs- oder Compliancefrist. Sektorale, vertragliche oder organisationsinterne Vorgaben bleiben gesondert zu prüfen.

Häufige Fehlannahmen

• „Passwortlos bedeutet automatisch phishing-resistent.“ Nein. Entscheidend sind bei WebAuthn die RP-ID-/Origin-Bindung, die signierte Assertion und deren vollständige Prüfung durch den Dienst.
• „Jede passwortlose Methode ist ein Passkey.“ Nein. Passwortlose Authentifizierung ist der weitere Oberbegriff; Passkeys sind eine mögliche Ausprägung.
• „Passkeys sind immer an genau ein Gerät gebunden.“ Nein. Es gibt sowohl synchronisierte Multi-Device-Credentials als auch gerätegebundene Single-Device-Credentials.
• „Jede Passkey-Anmeldung verlangt PIN oder Biometrie.“ Nein. Nutzerverifikation ist nur zwingend, wenn die Relying Party sie als erforderlich verlangt.
• „Passkeys machen Wiederherstellungsprozesse überflüssig.“ Nein. Für den Verlust gerätegebundener Zugangsdaten empfiehlt WebAuthn zusätzliche Authenticatoren und/oder einen Kontowiederherstellungsprozess.
• „Passwortlos ist automatisch Mehrfaktor-Authentifizierung.“ Nein. Aus dem Wegfall eines Passworts allein folgt keine bestimmte Zahl unabhängiger Authentifizierungsfaktoren.

Was die Geschäftsleitung tun sollte

Praxisempfehlung: Die folgenden Schritte sind risikobasierte Empfehlungen und keine allgemeine Passkey-Pflicht.

• Die vollständige serverseitige Validierung sowohl der Registrierungszeremonie als auch der Authentifizierungs-Assertion einschließlich der jeweils einschlägigen Challenge-, Kontozuordnungs-, Origin-, RP-ID- und Signaturprüfungen verbindlich in Architektur und Tests verankern.
• Code-Injection-Risiken begrenzen, insbesondere Risiken durch eingebundene Dritt-Skripte.
• Synchronisierte und gerätegebundene Passkeys anhand des Einsatzfalls bewerten und die Entscheidung einschließlich Verlust-, Gerätewechsel- und Wiederherstellungsszenarien dokumentieren.
• Für gerätegebundene Zugangsdaten zusätzliche Authenticatoren und/oder einen belastbaren Account-Recovery-Prozess vorsehen.
• Festlegen, bei welchen Konten und Risiken Nutzerverifikation verlangt wird, und sicherstellen, dass eine fehlgeschlagene oder verweigerte erforderliche Verifikation die Operation beendet.

Behördenpraxis: NIST empfiehlt innerhalb seines eigenen AAL-Modells, phishing-resistente Authentifizierung bei AAL2 nach Möglichkeit zu fördern; bei AAL3 verlangt das Modell einen phishing-resistenten Authenticator. Diese Einordnung gilt nur, wenn eine Organisation das NIST-Modell als Maßstab anwendet, und begründet keine allgemeine Passkey-Pflicht.

Für die Geschäftsleitung

Passkeys sind eine konkrete Form passwortloser Authentifizierung, aber weder alle passwortlosen Verfahren noch alle Passkeys haben identische Sicherheitseigenschaften. Entscheidend sind die korrekte WebAuthn-Prüfung, die Wahl zwischen synchronisierten und gerätegebundenen Zugangsdaten sowie belastbare Verlust- und Wiederherstellungsprozesse. Nachweisbar sein sollten die Risikobewertung, die Auswahlentscheidung, die technischen Prüfungen und Tests sowie die geregelten Recovery-Verfahren.

Quellen

• W3C: Web Authentication: An API for accessing Public Key Credentials – Level 3, insbesondere Abstract sowie die Abschnitte zu Web Authentication API, Assertion-Prüfung, Authenticator Data, Credential Storage Modality und Sicherheitsbetrachtungen.
• FIDO Alliance: Passkeys, insbesondere die Erläuterungen zu Passkeys sowie synchronisierten und gerätegebundenen Varianten.
• NIST SP 800-63B-4: Authentication and Authenticator Management, insbesondere die Anforderungen und Empfehlungen für AAL2 und AAL3.
• NIST SP 800-63B-4: Authenticator Requirements, insbesondere der Abschnitt zur Phishing-Resistenz.