Passkeys in der Praxis – Teil 2: Registrierung und Authentifizierung

Die technische Grundlage von Passkeys

Passkeys basieren auf einem kryptografischen Schlüsselpaar, das bei der Registrierung erzeugt und für zukünftige Anmeldungen genutzt wird. Die Abläufe, in der WebAuthn-Spezifikation als „Ceremonies“ bezeichnet, folgen einem festen Muster: Der Server initiiert eine Anfrage (Challenge), der Client-Authenticator signiert diese, und der Server validiert das Ergebnis. Während die Registrierung ein neues Credential erstellt, dient die Authentifizierung als Nachweis für den Besitz des privaten Schlüssels.

Die Registration Ceremony: Vorbereitung und Konfiguration

Der Prozess beginnt serverseitig mit der Erstellung eines `PublicKeyCredentialCreationOptions`-Objekts. Dieses ist entscheidend für Sicherheit und Nutzererfahrung.

Wichtige Parameter im Überblick

* **Challenge:** Ein kryptografisch zufälliger Byte-Puffer (empfohlen: 32 Bytes), der Replay-Angriffe verhindert. Sie darf nur einmal verwendet werden.

* **User-Objekt:** Die `user.id` sollte ein opaker Byte-Puffer ohne Personenbezug sein, idealerweise eine zufällig generierte UUID. Namen dienen lediglich der Anzeige in der Benutzeroberfläche.

* **Authenticator-Auswahl:** Über `authenticatorSelection` lässt sich steuern, ob ein „Resident Key“ (für passwortlose Logins) oder eine zwingende Nutzerverifizierung (Biometrie/PIN) erforderlich ist.

* **Algorithmen:** Mit `pubKeyCredParams` definiert der Server, welche kryptografischen Verfahren (z. B. ES256 oder RS256) unterstützt werden.

Validierung: Sicherheit durch strikte Prüfung

Nachdem der Nutzer den Authenticator bedient hat, erhält der Server ein `PublicKeyCredential`. Die Validierung ist ein kritischer Schritt, bei dem keine Kompromisse eingegangen werden sollten.

Pflichtschritte der serverseitigen Validierung

1. **ClientDataJSON-Prüfung:** Der Server muss den Typ (`webauthn.create`), die Challenge und den Ursprung (Origin) verifizieren. Letzteres ist essenziell, um Phishing-Angriffe abzuwehren.

2. **rpIdHash-Abgleich:** Der in den `authData` enthaltene Hash der Relying Party ID muss exakt mit dem SHA-256-Hash der erwarteten Domain übereinstimmen. Andernfalls wurde das Credential für eine falsche Instanz erstellt.

3. **Flag-Prüfung:** Das „User Presence“-Flag (UP) muss zwingend gesetzt sein. Wenn der Server eine Nutzerverifizierung verlangt hat, muss zudem das UV-Flag in den `authData` geprüft werden.

Speicherung und Verwaltung der Daten

Ein erfolgreicher Registrierungsprozess endet mit der Speicherung der relevanten Daten in der Datenbank des Servers. Für ein robustes System sollten mindestens folgende Informationen hinterlegt werden:

* **Credential ID und Public Key:** Die Basis für die spätere Authentifizierung.

* **SignCount:** Ein Zähler zur Erkennung von Klon-Versuchen.

* **AAGUID:** Identifikator für den Authenticator-Typ.

* **Flags für Backup-Status:** Die Felder `backupEligible` und `backupState` sind für moderne Implementierungen wichtig, um zu unterscheiden, ob ein Passkey synchronisiert werden kann oder aktuell synchronisiert ist.

Durch das Verständnis dieser Mechanismen können Entwickler sicherstellen, dass ihre Implementierung den Spezifikationen entspricht und keine sicherheitskritischen Abkürzungen nimmt. Die korrekte Handhabung der `authData` und die strikte Prüfung der `origin` bilden dabei das Fundament für eine vertrauenswürdige Anwendung.