Phishing-resistente Anmeldung mit WebAuthn und Passkeys

Worum es geht

Die Web Authentication API erlaubt einer Webanwendung, Public-Key-Anmeldeinformationen zu erzeugen und zu verwenden. Bei der Registrierung fordert navigator.credentials.create() einen Authentifikator (den plattformeigenen, entsperrt per Biometrie oder PIN, oder einen mobilen Sicherheitsschlüssel) auf, ein Schlüsselpaar zu erzeugen; der Server, Relying Party genannt, speichert den öffentlichen Schlüssel beim Konto. Bei der Anmeldung übergibt navigator.credentials.get() eine vom Server erzeugte Challenge; nach Zustimmung der Person signiert der Authentifikator sie mit dem privaten Schlüssel, und der Server prüft die Signatur mit dem gespeicherten öffentlichen Schlüssel. Die Spezifikation bindet jede Anmeldeinformation an eine Relying-Party-Kennung (RP-ID), eine Domain-Zeichenkette, die standardmässig der effektiven Domain des Origins entspricht und nur mit einem für sie registrierbaren Domain-Suffix überschrieben werden darf; eine Anmeldeinformation kann nur mit derselben Entität verwendet werden, identifiziert über die RP-ID, bei der sie registriert wurde, und die von der Signatur abgedeckten Client-Daten enthalten den Origin. Passkeys sind WebAuthn-Anmeldeinformationen, die entdeckbar sind (der Authentifikator speichert den privaten Schlüssel und das User Handle, sodass kein Benutzername zuerst eingegeben werden muss) und in vielen Implementierungen vom Plattformanbieter zwischen den Geräten einer Person synchronisiert werden. MDN merkt an, dass Passkeys im Web mit dieser API umgesetzt werden.

Warum es wichtig ist

Passwörter und Einmalcodes lassen sich auf eine Phishing-Seite eingeben und weiterleiten. MDNs Zusammenfassung der Schutzwirkung: Eine angreifende Person, die eine gefälschte Anmeldeseite erstellt, kann sich nicht als die betroffene Person anmelden, weil sich die Signatur mit dem Origin der Website ändert. Der Server hält kein Geheimnis, das wiederverwendet werden könnte, sodass eine geleakte Tabelle mit Anmeldeinformationen nur öffentliche Schlüssel offenlegt.

So wird es angewendet

• Eine gepflegte serverseitige Bibliothek für die Registrierungs- und Assertion-Abläufe verwenden; Challenge, Origin, RP-ID-Hash und Signatur prüfen sowie den Signaturzähler kontrollieren, wo der Authentifikator einen liefert.
• Die RP-ID bewusst wählen (die registrierbare Domain, falls mehrere Subdomains Konten teilen) und stabil halten; eine Änderung macht jede Anmeldeinformation ungültig.
• Mehrere Anmeldeinformationen pro Konto zulassen und die Kontowiederherstellung so gestalten, dass sie nicht schwächer ist als der Passkey, den sie ersetzt.
• Für passwortlose Anmeldung entdeckbare Anmeldeinformationen und Nutzerverifizierung anfordern; ist das Kontomodell dafür nicht bereit, Passkeys zunächst als zweiten Faktor anbieten.
• Die Credential-ID, den öffentlichen Schlüssel, den Signaturzähler und die Transports speichern; der private Schlüssel erreicht den Server nie.

Stolpersteine

Wiederherstellungsabläufe (Reset-Links per E-Mail, Support-Stellen) werden zum Phishing-Ziel, sobald der primäre Faktor phishing-resistent ist. Attestation ist optional, und MDN rät Relying Parties davon ab, Positivlisten von Authentifikatoren zu pflegen. Synchronisierte Passkeys verlagern das Vertrauen auf das Plattformkonto der Person; geräte-gebundene Anmeldeinformationen auf Sicherheitsschlüsseln synchronisieren nicht und brauchen eine zweite registrierte Anmeldeinformation. Browser- und Plattformdialoge unterscheiden sich; auf den tatsächlich genutzten Geräten testen.