Cybersicherheit

Passkeys für eine kleine Webanwendung — Was sich am Server ändert und was nicht

Geschrieben von Adam Muiz Aktualisiert: 27 Sep 2026 19 Min. gelesen
Passkeys für eine kleine Webanwendung — Was sich am Server ändert und was nicht

Es gibt einen bestimmten Moment im Leben einer kleinen Webanwendung, in dem das Login-Formular sich eher wie eine Haftung als wie ein Feature anfühlt. Passwörter werden geleakt, Menschen verwenden sie mehrfach, und ein zweiter Faktor bedeutet, jeden Nutzer zu bitten, einen kurzen rotierenden Code von einem Telefon abzulesen, das vielleicht in einem anderen Raum liegt. Passkeys werden genau in diesem Moment als Ausweg angeboten, und das Marketing darum ist selbstbewusst genug, dass man leicht annimmt, das Problem verschwinde einfach.

Es verschwindet nicht, und nicht alles bewegt sich in dieselbe Richtung. Meine Ausgangsfrage für diesen Text ist enger und praktischer: Wenn eine kleine Anwendung von Passwort plus Authenticator-App zu Passkeys wechselt, was ändert sich tatsächlich am Server, und was bleibt stur gleich?

Bevor ich weitergehe, möchte ich die Beweislage hinter diesem Artikel klarstellen. Die Tatsachenbehauptungen stammen aus zwei Dokumenten, die ich für die unten behandelten Punkte Abschnitt für Abschnitt durchgearbeitet habe, der Web Authentication Level 3 Specification und NIST SP 800-63B-4, ergänzt um Referenzdokumentation von MDN und OWASP. Das hier ist kein Bericht über einen Rollout. Ich habe Passkeys auf dieser Seite nicht implementiert, und ich habe keine Messung darüber, wie viele Konten tatsächlich eine Registrierung durchführen würden. Wo die Spezifikation Vorschriften macht, sage ich, was sie verlangt; wo sie die Entscheidung beim Implementierenden lässt, markiere ich das nach Möglichkeit als offene Frage, statt es als Best Practice zu verkleiden.

Was ein Passkey ist, genau genug um nützlich zu sein

Das Wort "Passkey" bezeichnet keinen eigenen Mechanismus: Das Glossar der Spezifikation führt es als einen weiteren Namen für eine Discoverable Credential. Bei der Registrierung erzeugt ein Authenticator ein Schlüsselpaar. Die private Hälfte bleibt beim Authenticator, was für einen Passkey, der zwischen Geräten synchronisiert wird, bedeutet, dass sie in den Speicher eines Anbieters kopiert werden kann, eine Komplikation, auf die ich später zurückkomme. Die öffentliche Hälfte geht an den Server und wird Ihrem Konto zugeordnet. Wenn Sie sich später anmelden, signiert der Authenticator einen vom Server gelieferten Challenge mit dem privaten Schlüssel, und der Server prüft diese Signatur gegen den öffentlichen Schlüssel, den er bereits besitzt. Über das Netz gehen ein öffentlicher Schlüssel und eine Signatur, die an einen frischen Challenge gebunden ist, kein wiederverwendbares Geheimnis.

Bei einem zeitbasierten Einmalpasswort ist die Anordnung anders. NIST beschreibt ein Single-Factor-OTP-System als System mit zwei persistenten Werten: einem symmetrischen Schlüssel, der die Lebensdauer des Authenticators überdauert, und einem Nonce, der sich bei jeder Verwendung ändert oder aus einer Echtzeituhr abgeleitet wird. Der erwartete Code wird aus Schlüssel und Nonce berechnet, der Verifizierer braucht also den Schlüssel selbst und kann nicht nur dessen Hash aufbewahren. Sie können die Versuche mit diesem Code begrenzen, das Geheimnis im Ruhezustand verschlüsseln und einschränken, wer es lesen darf, und nichts davon ändert die Tatsache, dass der Server Material hält, das einen gültigen Code erzeugen kann. Ein Passkey beseitigt diese Art von Problem für die Credential selbst.

Die Richtlinie von NIST zieht eine schärfere Grenze zwischen beiden, und der Grund hat mit Phishing zu tun. Sie hält fest, dass Authenticator, die eine manuelle Eingabe eines Authenticator-Outputs erfordern, wobei Out-of-Band- und OTP-Authenticator ausdrücklich genannt werden, shall not als phishing-resistent gelten, weil die manuelle Eingabe diesen Output nicht an die konkrete Sitzung bindet, die authentifiziert wird. WebAuthn wird in demselben Dokument als ein Standard beschrieben, der Phishing-Resistenz über Verifier Name Binding bereitstellt, indem er ein Authenticator Secret auf Basis des authentifizierten Domainnamens des Verifiers auswählt. Das ist eine Aussage über die Struktur des Protokolls, nicht darüber, wie aufmerksam Ihre Nutzer sind.

Drei Rollen sind für den Rest des Artikels wichtig, und die Spezifikation verwendet sie präzise. Der Relying Party ist die Seite, die Sie verifizieren möchte, das heißt Ihr Server. Der User Agent ist der Browser, und er stellt eine API bereit, damit eine Seite mit Hardware sprechen kann, die sie nicht kontrolliert. Der Authenticator ist das, was tatsächlich den privaten Schlüssel hält: etwas, das in den User Agent oder das Betriebssystem integriert ist, etwa Windows Hello, oder ein physisches Token wie ein USB- oder Bluetooth-Sicherheitsschlüssel. Das Glossar fügt einen Begriff hinzu, der gerade für Passkeys wichtig ist: eine Client Platform ist ein Client Device zusammen mit einem Client, und dasselbe Hardware-Gerät kann im Laufe der Zeit Teil mehrerer unterschiedlicher Client Platforms sein, wenn es verschiedene Betriebssysteme und/oder Clients ausführt.

Im Web sind Passkeys WebAuthn, und MDN kennzeichnet die API als seit September 2021 browserübergreifend verfügbar und weist zugleich darauf hin, dass sie nur in sicheren Kontexten funktioniert, also über HTTPS. Ich würde diese Kombination als Voraussetzung für jede Adoption lesen: Eine Browser-API, die nur hinter einem Zertifikat funktioniert, das der durchschnittliche Besucher nicht hat, hätte Passkeys in Hobby-Projekte verbannt.

Die beiden Zeremonien sind die eigentliche Arbeit

Registrierung und Authentifizierung werden üblicherweise als ein einziger Ablauf beschrieben, und das verdeckt genau den Teil, der entscheidet, ob eine Implementierung korrekt ist. Es sind zwei getrennte Zeremonien, und für jede hat der Server eine Prüfliste. Level 3 der Spezifikation formuliert diese Listen ausdrücklich, und eine kleine Anwendung kann sie durchaus umsetzen, allerdings nur, wenn sie sie als Checkliste behandelt und nicht als Bibliotheksaufruf mit Sicherheitsglanz.

Die Registrierung beginnt damit, dass der Server eine Challenge erzeugt, sie an den Browser sendet und der Browser den Authenticator auffordert, eine Credential zu erstellen. Der Authenticator liefert den frisch erzeugten öffentlichen Schlüssel, eine Kennung dafür und eine Attestation Statement zurück. Der Server prüft dann unter anderem, ob der Hash der Relying Party Identifier in den Authenticator Data mit der erwarteten Kennung übereinstimmt, ob das User-Presence-Bit gesetzt ist, sofern die Anfrage nicht aus einem bedingten Autofill stammt, ob das User-Verification-Bit gesetzt ist, wenn der Server User Verification verlangt hat, ob die Backup-State-Bits in sich konsistent sind, ob der Algorithmus einem vom Server angebotenen entspricht und ob die Credential Identifier noch keinem anderen Nutzer zugeordnet ist. Level 3 begrenzt Credential Identifier auf 1023 Bytes und erklärt, dass größere die Zeremonie scheitern lassen sollten.

Diese letzte Prüfung ist nicht Pedanterie. Die Spezifikation begründet sie: Ein Angreifer, der sich den Credential Identifier und den Credential Public Key eines Nutzers für eine Seite verschafft hat, könnte versuchen, die Credential des Opfers als eigene zu registrieren, und das Ablehnen einer bereits bekannten Kennung ist es, was diese Substitution verhindert.

Die Authentifizierung sieht von außen einfacher aus und ist der Punkt, an dem ich bei einer selbstgebauten Implementierung einen Bruch erwarten würde. Der Server stellt eine frische Challenge aus, der Browser liefert eine signierte Assertion, und der Server prüft eine Liste, die ich in Alltagssprache wiedergeben möchte, weil die Reihenfolge zählt:

  • der Typ in den Client Data ist webauthn.get;
  • die Challenge entspricht dem soeben ausgestellten, base64url-kodiert;
  • der Origin ist einer, den der Server erwartet;
  • der Hash der Relying Party Identifier entspricht der Kennung, die der Server erwartet;
  • das User-Presence-Bit ist gesetzt, das User-Verification-Bit, wenn Verification verlangt war;
  • die Signatur ist über die Verkettung von Authenticator Data und Hash der Client Data gültig.

Jede dieser Prüfungen hat eine bestimmte Aufgabe. Die Challenge-Prüfung stoppt Replay. Die Origin-Prüfung bindet die Assertion an Ihre Seite. Die Prüfung der Relying Party Identifier verhindert, dass eine für eine andere Seite registrierte Credential hier verwendet wird.

Die Challenge verdient einen zweiten Blick, weil die Spezifikation dazu ungewöhnlich direkt ist. Ein eigener Abschnitt legt fest, dass sowohl die Challenge für die Erstellung als auch die für die Anfrage zufällig vom Relying Party in einer von ihm vertrauten Umgebung, etwa auf dem Server, erzeugt werden muss und der zurückgegebene Wert mit dem erzeugten übereinstimmen muss. Derselbe Abschnitt sagt, der Relying Party solle die Challenge vorübergehend speichern, bis der Vorgang abgeschlossen ist, solle sie nur für einen Zeitraum gültig halten, der der Obergrenze eines Ceremony Timeouts ähnelt, und solle sie mindestens 16 Byte lang machen. In der Praxis heißt das: Die Challenge ist sitzungsgebunden, kurzlebig und einmalig verwendbar, und sie geringer zu behandeln entfernt still den Replay-Schutz, für den die übrige Liste existiert.

Ein weiteres Detail wird leicht übersehen. Level 3 legt fest, dass User Verification verlangt werden sollte, wenn und nur wenn die Anfrage sie auf required gesetzt hat. Wenn Ihr Server nicht danach fragt, weist die Spezifikation an, den User-Verification-Bit zu ignorieren, statt ihn als unerwartet erhaltenen zusätzlichen Faktor zu behandeln.

Discoverable Credentials und der Autofill-Dialog

Es gibt zwei Wege, wie ein Server einen Authenticator auf eine bestimmte Credential richten kann. Bei einer Non-Discoverable Credential liefert der Server die gespeicherte Credential Identifier, weshalb der Nutzer meist zuerst einen Benutzernamen eingeben muss. Bei einer Discoverable Credential liefert der Server nichts, und der Authenticator kann jede Credential anbieten, die er für diesen Relying Party hält. Level 3 hat diesen Bereich umbenannt, und die Namensgeschichte ist eine kleine Erinnerung daran, wie jung das Feld ist: "Discoverable Credential" ist der Begriff der Spezifikation, während "Resident Key" aus Gründen der Abwärtskompatibilität in der API und im Datenmodell weiterlebt.

MDN nennt eine Folge, die für jede Website mit bestehendem Passwort-Login praktisches Gewicht hat: Definitionsgemäß müssen Passkeys immer Discoverable Credentials sein. Genau das ermöglicht die Autofill-Erfahrung, bei der der Browser Nutzer einlädt, sich mit einem Passkey anzumelden, wenn und nur wenn gerade ein geeigneter Passkey verfügbar ist, statt sie zu zwingen, sich zwischen zwei Mechanismen zu entscheiden. Die Markup-Änderung ist ein zusätzliches Token im autocomplete-Attribut, nämlich webauthn, das sowohl die Browser-Dokumentation als auch die Spezifikation beschreibt. Für eine bereits passwortbasierte Website ist das womöglich der Unterschied zwischen einer Passkey-Option, die genutzt wird, und einer, an der alle vorbeiscrollen.

Die Flags sind der ehrliche Teil der Geschichte

WebAuthn Authenticator Data trägt eine kleine Menge von Flags, und dort zeigen sich die interessanten Zielkonflikte. Vier davon sollte man kennen: User Present, User Verified, Backup Eligible und Backup State.

Die ersten beiden sind die vertrauten. Das zweite Paar ist in der Praxis neuer und weit weniger diskutiert. Level 3 definiert die Kombinationen, und die Tabelle ist kurz genug zum Zitieren:

Backup eligibleBackup stateBedeutung
00Einzelgeräte-Credential.
01Nicht zulässig.
10Mehrgeräte-Credential, derzeit nicht gesichert.
11Mehrgeräte-Credential, derzeit gesichert.

Quelle: WebAuthn Level 3, Credential Backup State.

Die Semantik ist wichtiger, als die Tabelle vermuten lässt. Eine Credential, die synchronisiert werden kann, eine, die anderswohin kopiert werden kann, und eine, die tatsächlich kopiert wurde, sind drei verschiedene Dinge, und nur das letzte meldet das Backup-State-Flag. Backup Eligible wird während der Credential-Erstellung gesetzt und darf sich danach nicht ändern, während der Backup State sich im Laufe der Zeit ändern kann. Die Spezifikation empfiehlt, dass Relying Parties die aktuellsten Werte speichern, und schlägt dann Verhaltensweisen vor, die auf den ersten Blick weniger offensichtlich sind.

Ist eine Credential nicht Backup Eligible, ist sie eine Einzelgeräte-Credential, deren erzeugender Authenticator sie niemals sichern lassen wird, und die Spezifikation sagt, ein Relying Party solle sicherstellen, dass jedes Konto zusätzliche Authenticator und/oder einen Recovery-Prozess hat. Springt der Backup State von null auf eins, ist die Credential gegen den Verlust eines einzelnen Geräts geschützt, und der Server darf den Nutzer auffordern, die Kontosicherheit zu erhöhen und sein Passwort zu entfernen. Springt er von eins zurück auf null, weil ein Backup-Dienst abgeschaltet wurde oder schlicht ausgefallen ist, sollte der Relying Party den Nutzer durch einen Prozess führen, um seine anderen Authentifizierungsfaktoren zu validieren, und falls er keine weiteren hat, durch das Hinzufügen eines.

Diesen letzten Fall sollte man lesen, für was er ist: Ein Passkey-Einsatz ist eine Zustandsmaschine für Konten, die nun bemerken muss, dass sich ein Bit dreht, und dann einer Person durch die Folgen helfen muss. Für einen Ein-Personen-Blog ist das ein Feature, das man überspringen kann. Für eine Anwendung mit echten Konten ist es eine Entwurfsaufgabe, kein Feinschliff.

NISTs Hinweise zu denselben Flags sind vorsichtiger, und ich halte sie für den öffentlich zugänglichen Text für den nützlicheren. In seinem Anhang zu syncable Authenticators sagt SP 800-63B-4, ein Verifier darf das Backup-Eligible-Flag verwenden, um syncable Authenticator einzuschränken, Behörden sollten die Annahme bei öffentlich zugänglichen Anwendungen jedoch nicht vom Backup-State-Flag abhängig machen, und zwar wegen der Benutzererfahrung. Dasselbe Dokument warnt davor, die fehlende Verfügbarkeit von Attestations syncable Authenticator nicht blockieren zu lassen, weil Attestations in Consumer-Produkten begrenzt verfügbar sind und ihre Vorschreibung Nutzer wahrscheinlich auf weniger sichere Optionen umlenkt.

Das ist eine nützliche Korrektur der Begeisterung für diese Flags. Sie sind informativ, keine Policy Engine, und eine kleine Anwendung, die synchronisierte Credentials anhand des Backup State ablehnt, erzeugt im Wesentlichen Support-Anfragen.

Der Signature Counter ist ein Signal, kein Beweis

Authenticator Data enthält außerdem einen Signature Counter, signCount, und die Spezifikation ist bemerkenswert ehrlich über seine Grenzen. Authenticator sollten ihn implementieren, doch diejenigen, die das nicht tun, lassen den Wert konstant bei null, sodass ein Relying Party auf beiden Seiten null behandeln muss. Selbst wenn beide Werte ungleich null sind, weist ein neuer Wert, der kleiner oder gleich dem gespeicherten ist, lediglich darauf hin, dass etwas möglicherweise nicht stimmt: Zwei oder mehr Kopien des privaten Credential-Schlüssels könnten existieren und parallel genutzt werden, der Authenticator könnte defekt sein, oder der Relying Party selbst könnte Assertions in einer anderen Reihenfolge verarbeiten als sie erzeugt wurden. Die Spezifikation bezeichnet das ausdrücklich als Signal, nicht als Beweis, und überlässt die Entscheidung, ob die Zeremonie scheitern soll, dem Implementierenden.

Derselbe Abschnitt fordert Authenticator auf, pro Credential gezählte Counter statt eines globalen zu implementieren, weil ein gemeinsam genutzter Counter als Correlation Handle für den Nutzer über Websites hinweg dienen könnte. Es lohnt sich zu bemerken, was diese Erörterung voraussetzt. Der Abschnitt zu Security Considerations der Spezifikation stellt fest, dass sie kein Protokoll für die Sicherung privater Credential-Schlüssel oder für deren Weitergabe zwischen Authenticators definiert und dass im Allgemeinen erwartet wird, dass ein privater Credential-Schlüssel den Authenticator, der ihn erzeugt hat, nie verlässt. Für eine Credential, deren gesamter Zweck es ist, zwischen Geräten kopiert zu werden, ist Counter-basierte Klonerkennung einer der schwächeren Gründe für ein beruhigendes Gefühl, und ich habe keine Anforderung in der Spezifikation gefunden, dass eine solche Credential einen aussagekräftigen Counter melden muss.

Was sich nicht ändert: Recovery

Das ist der Teil, den ich bei jeder Passkey-Entscheidung ganz nach oben setzen würde, und zugleich der Teil, der in Vergleichen am häufigsten fehlt. Das Entfernen des geteilten Geheimnisses aus Ihrem Login beseitigt nicht das Bedürfnis, eine Person zurück in ihr Konto zu bekommen, die den Zugang verloren hat.

NIST behandelt Account Recovery als ein vom Authentifizieren getrenntes Ereignis und erkennt vier Klassen von Methoden an: gespeicherte Recovery Codes, ausgestellte Recovery Codes, Recovery Contacts und wiederholte Identitätsprüfung. In der Formulierung von NIST muss ein Credential Service Provider mindestens eine davon unterstützen. Für gespeicherte Recovery Codes muss der Code mindestens 64 Bit aus einem genehmigten Zufallsbitgenerator enthalten, in der Form eines Hashes im Konto gespeichert und für die Offline-Aufbewahrung durch den Abonnenten gedacht sein. Ein Account-Recovery-Ereignis löst immer mindestens eine Benachrichtigung aus, und zwar genau damit, betrügerische Recovery bemerkbar wird.

Es lohnt sich, den Geltungsbereich hier im Blick zu behalten. SP 800-63B ist für US-Bundesbehörden geschrieben und bindet eine kleine Website nicht; der Abstract beschreibt Richtlinien für Personen, die mit Government Information Systems interagieren. Es ist schlicht die ausführlichste öffentliche Richtlinie zu dieser Frage, die ich gefunden habe, und ihre Begründung ist nicht auf eine bestimmte Regierung beschränkt.

Neben der Credential-Geschichte gelesen lautet die ehrliche Zusammenfassung so. Passkeys verbessern die Sicherheit dessen, womit Sie verifizieren. Sie tun absolut nichts für den Prozess, mit dem Sie Identität wiederherstellen, wenn das Ding verschwunden ist. Eine Anwendung, die Passkeys einführt und ihren Passwort-Reset-Pfad genauso schwach lässt wie zuvor, hat die Arbeit nicht beendet und es möglicherweise schlimmer gemacht, denn der Reset-Pfad ist jetzt der einzige verbleibende Weg hinein. Die Antwort der Spezifikation auf Credential Loss ist kein Backup-Mechanismus, sondern Breite: Relying Parties sollten Nutzern erlauben und sie dazu ermutigen, mehrere Credentials für dasselbe Konto zu registrieren, damit der Verlust eines Geräts nicht dem Verlust des Kontos entspricht.

Ein zweites "ändert sich nicht" ist klar auszusprechen. Passkeys beantworten die Authentifizierungsfrage. Sie sagen nichts über Autorisierung, nichts darüber, was ein authentifizierter Nutzer tun darf, und nichts über die darauffolgende Session. Eine gültige Passkey-Assertion, die einen langlebigen, schlecht begrenzten Session-Cookie erzeugt, hat denselben Fehler nur eine Ebene nach oben geschoben, und deshalb wird die bestehende Beratung zu Session Identifier, Cookie-Flags und Idle Timeouts durch nichts in diesem Artikel berührt.

Zwei Kritikpunkte, die man ernst nehmen sollte

Der erste betrifft das Teilen. Passwortteilen ist schlecht, und das Teilen von Passkeys ist ein Feature, das manche Implementierungen inzwischen bewusst anbieten. NIST ist hier ungewöhnlich direkt: Die Richtlinien haben traditionell davor gewarnt, Authenticator zwischen Nutzern zu teilen, manche Syncable-Implementierungen fördern das Teilen aktiv als bequemere und sicherere Alternative zum Teilen eines Passworts, die für Enterprise Device Management vorhandenen Gegenmaßnahmen haben keine Entsprechung für öffentlich zugängliche Anwendungen, und eine Behörde in dieser Lage sollte davon ausgehen, dass alle syncable Authenticator geteilt werden können. Was Passkeys auch sonst tun, sie lassen das Teilen von Konten nicht verschwinden, und sie übergeben einen Teil dieser Politik an denjenigen, der die synchronisierte Kopie speichert.

Der zweite betrifft die Annahme von Hardware. Es ist verlockend anzunehmen, ein Passkey liege in einem Secure Element und lasse sich nicht extrahieren. Die Authentifizierungsempfehlungen von OWASP gehen diese Annahme nicht einfach ein: Bei vielen Authenticators, einschließlich gängiger Plattform-Passkeys, wird der private Schlüssel vom Secure Key Manager des Betriebssystems erzeugt und gespeichert. Schlüssel können je nach Plattform und Authenticator durch hardwaregestützte Komponenten wie das TPM unter Windows, die Secure Enclave auf Apple-Geräten oder den Android Keystore und StrongBox geschützt werden, oder durch andere softwarebasierte Mechanismen. Allerdings unterstützen manche Authenticator eine Synchronisierung oder Sicherung, die Export oder serverseitige Speicherung einschließen kann, und nicht alle Implementierungen sind hardwaregestützt. Die ausdrückliche Empfehlung lautet, nicht anzunehmen, Schlüssel seien hardwaregestützt und nicht exportierbar, solange dies nicht überprüft wurde, etwa über Authenticator Properties oder Attestation.

Beide Kritikpunkte zeigen auf dieselbe strukturelle Verschiebung. Die Sicherheit von Passkeys hängt an einer Kette, die nun ein Gerät, ein Betriebssystem, eine Client Platform und meist ein Cloud-Konto mit der synchronisierten Kopie umfasst. Diese Kette ist im Allgemeinen stärker als ein geteiltes Geheimnis in einer Datenbank, aber sie ist nicht eine, die Sie vollständig kontrollieren.

Eine Entscheidungs-Checkliste für eine kleine Anwendung

Wenn Sie eine kleine Website betreiben und Passkeys erwägen, sind die Fragen, die ich zuerst beantworten würde, nicht die technischen:

  • Haben Sie pro Konto mehr als einen Authenticator oder eine Recovery-Methode? Die Spezifikation empfiehlt beides, und eine Website mit einem einzigen Administrator, der einen Laptop besitzt, sollte ernsthaft darüber nachdenken, wer den Zugang wiederherstellt, wenn das Laptop weg ist.
  • Behalten Sie einen Passwortpfad zusätzlich bei? Beides zu behalten ist normal, und das in der Spezifikation beschriebene Upgrade auf eine passwortlose Form bedeutet nur etwas, solange noch ein Passwort vorhanden ist, das entfernt werden kann. Jeder zusätzliche Pfad ist ein weiterer Pfad, der gehärtet werden muss.
  • Verifizieren Sie die Zeremonie selbst oder verwenden Sie eine gepflegte Bibliothek? Es gibt Implementierungen für PHP, die gepflegt werden, etwa das Projekt web-auth/webauthn-framework, das sich selbst als Sammlung von PHP-Bibliotheken und einem Symfony Bundle zur Integration von WebAuthn in Webanwendungen beschreibt, veröffentlicht unter der MIT-Lizenz. Eigenes COSE- und CBOR-Handling zu schreiben, um eine Abhängigkeit zu sparen, ist ein schlechter Handel für ein kleines Team.
  • Können Sie Ihre Session-Behandlung erklären, ohne das Wort "Passkey" zu benutzen? Wenn die Antwort nein lautet, ist die Reihenfolge falsch.

Es gibt außerdem eine Versionsfrage. WebAuthn Level 3 ist im August 2026 eine W3C Recommendation geworden und hat in seiner API und seinem Datenmodell bewusst ältere Namen für die Kompatibilität beibehalten, wie der Abschnitt zu Discoverable Credentials zeigt. Bibliotheken und Plattform-APIs werden nicht nach demselben Zeitplan aktualisiert wie die Spezifikation, daher verdient die Version, gegen die Sie implementieren, eine Notiz in Ihrer Implementationsdokumentation und eine erneute Durchsicht, wenn diese Version wechselt.

Was ich weiterhin nicht weiß

Mehrere praktische Fragen bleiben für mich offen, und ich möchte sie lieber benennen als sie zu überdecken. Wie gut ein bestimmtes CMS-Plugin oder Framework das integriert, ohne dass Abstraktionsprobleme durchschlagen, habe ich nicht bewertet. Ob die Autofill-Erfahrung für eine kleine Website tatsächlich Support-Tickets reduziert oder lediglich Verwirrung vom Login-Formular in den Browser verlagert, ist eine empirische Frage, für die ich keine Daten habe. Und die schwierigere Frage darunter: Wie viel der Sicherheitsgeschichte übersteht ein Nutzer, der nie einen Passkey aktiviert und einfach sein vorhandenes Passwort behält.

Diese letzte Frage ist der Grund, warum ich das nicht als Ersatz bezeichnen würde. Für eine kleine Anwendung sehen Passkeys am besten aus als starke zweite Option auf einer Login, der bereits gesund ist, nicht als Neuschreibung, die die Probleme auflöst, auf die es ankommt.

References