Das Ende des Passworts: Passkeys, WebAuthn und die Anatomie phishing-resistenter Anmeldung

Der Aufhänger: Ein Geheimnis, das man nicht verraten kann

Stell dir einen Angriff vor, der seit dreißig Jahren funktioniert und dessen Erfolgsquote mit besserer Technik nicht sinkt, sondern steigt. Jemand baut eine Seite, die aussieht wie das Anmeldeformular deines Arbeitgebers. Du gibst dein Passwort ein. Die Seite leitet es in Echtzeit an den echten Dienst weiter, bekommt die Aufforderung zum zweiten Faktor zurück, zeigt sie dir, du tippst die sechs Ziffern aus der App ein, die Seite reicht sie weiter – und der Angreifer hält am Ende ein gültiges Sitzungscookie in der Hand. Dein zweiter Faktor hat nichts verhindert. Er hat den Angriff nur um vier Sekunden verlängert.

Dieses Muster heißt Adversary-in-the-Middle, und die einschlägigen Werkzeuge dafür sind seit Jahren öffentlich, gut dokumentiert und einfach zu bedienen. Microsoft berichtet in seiner Bestandsaufnahme zum World Passkey Day 2026 von Phishing-Kampagnen, die mit KI-generierten Texten Klickraten von bis zu 54 Prozent erreichen – also mehr als jeder zweite Empfänger klickt. Gleichzeitig nennt das Unternehmen eine bemerkenswerte Gegenzahl: Im eigenen internen Umfeld sind 99,6 Prozent der Nutzer und Geräte auf phishing-resistente Authentifizierung umgestellt.

Diese beiden Zahlen gehören zusammen, denn sie beschreiben denselben Befund aus zwei Richtungen. Solange die Anmeldung darauf beruht, dass der Nutzer ein Geheimnis kennt und es an die Gegenstelle überträgt, kann man ihn dazu bringen, es an die falsche Gegenstelle zu übertragen. Kein Schulungsprogramm ändert etwas an diesem strukturellen Problem, weil es kein Wissensproblem ist, sondern ein Protokollproblem: Das Passwort ist ein Inhaberzeichen. Wer es hat, ist drin. Es enthält keine Information darüber, wem es gerade gezeigt wird.

Passkeys drehen diese Eigenschaft um. Sie ersetzen das geteilte Geheimnis durch ein Schlüsselpaar, dessen privater Teil das Gerät nie verlässt, und sie binden jeden einzelnen Anmeldevorgang kryptographisch an die Domain, die ihn angefordert hat. Das entscheidende Detail ist nicht die Biometrie, nicht der Komfort und nicht das Verschwinden des Eingabefelds. Das entscheidende Detail ist, dass der Browser dem Authenticator mitteilt, mit wem er gerade spricht, und dass diese Angabe mit unterschrieben wird. Eine Signatur, die für login.beispiel-firma.de erzeugt wurde, ist auf login.beispiel-firma.com.evil.net wertlos – nicht weil ein Filter sie ablehnt, sondern weil sie mathematisch nicht passt.

Am 25. August 2026 hat das W3C die dritte Ausgabe des zugrundeliegenden Standards, Web Authentication: An API for accessing Public Key Credentials – Level 3, als offizielle Recommendation veröffentlicht. Die FIDO Alliance schätzt, dass weltweit rund fünf Milliarden Passkeys im Einsatz sind. Damit ist das Thema aus der Phase der Zukunftsversprechen heraus und in die Phase gerückt, in der Architekturentscheidungen getroffen werden müssen. Dieser Artikel erklärt den Mechanismus so genau, dass man ihn implementieren könnte – und anschließend ebenso genau, wo er nicht schützt.

Teil 1: Warum das Passwort scheitert – und warum MFA es nur verzögert

Das Passwort als Inhaberzeichen

Ein Passwort hat eine Eigenschaft, die alle seine Probleme erklärt: Es ist ein wiederverwendbares, übertragbares Geheimnis ohne Kontextbindung. Drei Adjektive, drei Angriffsklassen.

Wiederverwendbar: Dasselbe Geheimnis wird bei jeder Anmeldung erneut vorgezeigt. Wer es einmal beobachtet, kann es beliebig oft verwenden. Ein Einmal-Code behebt genau diese Eigenschaft – und nur diese.

Übertragbar: Der Nutzer muss das Geheimnis an die Gegenstelle senden, damit sie es prüfen kann. Damit existiert es zwangsläufig für einen Moment außerhalb seines Kopfes, im Browser, auf der Leitung, im Speicher des Servers. Jede dieser Stationen ist ein Ort, an dem es abgefangen oder falsch geleitet werden kann. Serverseitiges Hashing mit Argon2 oder bcrypt schützt das Geheimnis nach der Prüfung, nicht während der Übertragung an den falschen Empfänger.

Ohne Kontextbindung: Das Geheimnis selbst enthält keine Information darüber, für welchen Dienst es gedacht ist. Ein Passwortmanager hilft hier erheblich, weil er die Kontextbindung nachträglich einführt: Er füllt das Feld nur auf der gespeicherten Domain aus. Aber diese Bindung ist eine Komfortfunktion des Clients, keine Eigenschaft des Protokolls – und der Nutzer kann sie jederzeit übergehen, indem er von Hand kopiert.

Bemerkenswert ist, wie gut das Passwort trotzdem ist. Joseph Bonneau, Cormac Herley, Paul van Oorschot und Frank Stajano haben 2012 auf dem IEEE Symposium on Security and Privacy eine Arbeit vorgelegt, die bis heute den Bewertungsrahmen liefert: The Quest to Replace Passwords. Sie bewerteten über dreißig Alternativverfahren anhand von 25 Kriterien in drei Gruppen – Usability, Deployability, Security – und kamen zu einem Ergebnis, das die Branche seither begleitet: Kein einziges Verfahren dominierte das Passwort in allen drei Dimensionen. Fast jede Alternative war sicherer, aber schlechter einführbar oder unbequemer. Das Passwort gewinnt nicht, weil es gut ist, sondern weil es in Deployability nahezu unschlagbar ist: null Kosten, null Hardware, funktioniert auf jedem Gerät, jedem Browser, in jedem Land.

Die Relevanz dieser Arbeit für Passkeys liegt genau dort. Die spannende Frage ist nicht, ob Passkeys sicherer sind als Passwörter – das ist trivial zu bejahen. Die spannende Frage ist, ob sie das Deployability-Defizit aller Vorgänger überwunden haben. Genau darauf zielt die Entwicklung der letzten Jahre ab, und genau daraus erklären sich die Kompromisse, die synchronisierte Passkeys eingehen.

Warum der zweite Faktor das Problem nicht löst

Mehrfaktor-Authentifizierung wird gern als Lösung des Phishing-Problems verkauft. Das ist sie nur für bestimmte Faktoren. Die gängigen Verfahren zerfallen in zwei Gruppen mit völlig unterschiedlichem Verhalten unter Angriff:

Der entscheidende Trennstrich verläuft nicht zwischen „ein Faktor" und „zwei Faktoren", sondern zwischen Verfahren, bei denen der Nutzer etwas überträgt, und Verfahren, bei denen das Gerät etwas über den Kontext signiert. Alles, was man abtippen, vorlesen oder antippen kann, lässt sich weiterleiten. Der Fachbegriff in der Normungsliteratur dafür ist Verifier Impersonation Resistance – Widerstand dagegen, dass sich ein Angreifer als der prüfende Dienst ausgibt. Das NIST hat diesen Begriff in der aktuellen Fassung seiner Digital Identity Guidelines in den heute üblicheren Terminus Phishing Resistance überführt.

Diese Guidelines, NIST SP 800-63-4, wurden im August 2025 final veröffentlicht und lösen die seit 2017 gültige Revision 3 ab. Der für unser Thema entscheidende Teilband ist SP 800-63B-4 zu Authentifizierung und Authenticator-Management. Er formuliert die Anforderung erstmals scharf: Auf Assurance Level AAL2 SHALL ein Verifier mindestens eine phishing-resistente Option anbieten; für Bundesbehörden ist deren Nutzung verpflichtend. Auf AAL3 ist Phishing-Resistenz nicht nur eine Option, sondern Pflicht – und zusätzlich muss der private Schlüssel nicht exportierbar sein. Dieser eine Halbsatz entscheidet, wie wir später sehen werden, über die Zulässigkeit synchronisierter Passkeys in hochsicheren Umgebungen.

Teil 2: Die Anatomie von WebAuthn

Drei Parteien, zwei Zeremonien

WebAuthn beschreibt ein Zusammenspiel von drei Rollen. Die Relying Party (RP) ist der Dienst, bei dem sich jemand anmeldet – die Webanwendung samt Server. Der Client ist üblicherweise der Browser oder das Betriebssystem; er ist nicht bloß Transportschicht, sondern trägt die sicherheitskritische Aufgabe, die Herkunft der Anfrage festzustellen und zu bezeugen. Der Authenticator ist die Komponente, die Schlüssel erzeugt und benutzt: ein Secure Enclave im Telefon, ein TPM im Notebook, ein USB-Sicherheitsschlüssel oder ein Passwortmanager mit Passkey-Unterstützung.

Zwischen diesen Rollen laufen zwei Abläufe, die der Standard Zeremonien nennt: die Registrierung (navigator.credentials.create()) und die Authentifizierung (navigator.credentials.get()).

Registrierung: ein Schlüsselpaar, das nur für diese Domain existiert

Bei der Registrierung sendet der Server eine PublicKeyCredentialCreationOptions-Struktur an den Browser. Darin stehen unter anderem eine frische, zufällige Challenge, die RP ID (in der Praxis die Domain, etwa beispiel-firma.de), Angaben zum Nutzerkonto, die akzeptierten Signaturalgorithmen und die Anforderungen an den Authenticator.

Der Authenticator erzeugt daraufhin ein neues asymmetrisches Schlüsselpaar – typischerweise ECDSA über P-256 oder Ed25519 – und zwar ausschließlich für diese RP ID. Er behält den privaten Schlüssel, gibt den öffentlichen Schlüssel heraus, dazu eine Credential ID als Handle und optional eine Attestation: eine Signatur des Herstellers darüber, welcher Gerätetyp den Schlüssel erzeugt hat, identifiziert über die AAGUID. Der Server speichert öffentlichen Schlüssel, Credential ID und die Metadaten. Er speichert kein Geheimnis. Ein Datenbankleck beim Dienst gibt einem Angreifer nichts, womit er sich anmelden könnte – ein Unterschied zu Passwort-Hashes, die man offline angreifen kann.

Wichtig ist, was hier nicht passiert: Biometrische Daten verlassen das Gerät nie. Fingerabdruck oder Gesichtsscan entsperren lokal den Zugriff auf den privaten Schlüssel. Der Dienst erfährt nur, dass eine Nutzerverifikation stattgefunden hat, nie wie. Das ist keine Implementierungsgewohnheit, sondern eine Eigenschaft des Protokolls: In der Signatur steckt lediglich ein einzelnes Flag.

Authentifizierung: wo die Phishing-Resistenz entsteht

Bei der Anmeldung schickt der Server eine neue Challenge. Der Browser stellt dem Authenticator eine Datenstruktur zur Verfügung, die im Standard CollectedClientData heißt und serialisiert als clientDataJSON übertragen wird. Sie enthält laut Spezifikation:

• type – die Art der Zeremonie, also "webauthn.create" oder "webauthn.get",
• challenge – die Zufallsnonce des Servers, base64url-kodiert,
• origin – die vom Browser festgestellte Herkunft der Anfrage, also Schema, Host und Port,
• crossOrigin – ob der Aufruf aus einem eingebetteten Kontext kam,
• optional topOrigin – bei Aufrufen aus einem iframe die Herkunft des äußersten Dokuments.

Der Client hasht diese Serialisierung. Der Authenticator signiert die Verkettung aus diesem Hash und den authenticatorData – also RP-ID-Hash, Flags und Signaturzähler. Das Ergebnis geht zurück an den Server, der mit dem gespeicherten öffentlichen Schlüssel prüft.

Und hier liegt der ganze Trick, in einem Satz: Das Feld origin wird nicht von der Webseite gesetzt, sondern vom Browser, und es wird mit signiert.

Damit ist der Phishing-Angriff nicht erschwert, sondern strukturell ausgeschlossen. Spielen wir ihn durch. Ein Angreifer betreibt beispiel-firma-login.net und proxyt alles zur echten Seite weiter. Der Nutzer fällt darauf herein und bestätigt die Anmeldung per Fingerabdruck. Zwei Dinge gehen jetzt schief, und zwar unabhängig voneinander:

1. RP-ID-Scoping. Der Authenticator sucht ein Credential für die RP ID beispiel-firma-login.net. Es gibt keines, weil der Schlüssel für beispiel-firma.de registriert wurde. Der Standard formuliert das als grundlegende Eigenschaft: Die RP ID eines Credentials bestimmt seinen Geltungsbereich. Die Anmeldung scheitert, bevor überhaupt etwas signiert wird. Der Nutzer sieht keine Passkey-Auswahl – bestenfalls einen Fehler.

2. Origin-Bindung. Selbst wenn der Angreifer es irgendwie schaffte, eine Signatur zu erhalten, stünde in der signierten Struktur "origin":"https://beispiel-firma-login.net". Der echte Server vergleicht dieses Feld mit seiner eigenen erwarteten Origin und lehnt ab. Die Signatur ist nicht wiederverwendbar, weil sie den Kontext ihrer Entstehung mitträgt.

Man kann diesen Mechanismus auf eine Formel bringen, die in der Kryptographie immer wieder auftaucht: Statt ein Geheimnis vorzuzeigen, wird ein Beweis erzeugt, der an genau die Umstände gebunden ist, unter denen er gültig sein soll. Es ist derselbe Gedanke wie bei Channel Binding in TLS oder bei der Bindung eines Tokens an eine Zielgruppe. Die Sicherheit kommt nicht aus der Geheimhaltung allein, sondern aus der Kontextbindung.

Flags, Zähler und die Grenzen der Erkennung

Die authenticatorData enthalten zwei Flags, die man in der Praxis oft verwechselt. UP (User Present) bedeutet: Eine Person hat physisch etwas getan – den Schlüssel berührt, den Bildschirm angetippt. UV (User Verified) bedeutet: Der Authenticator hat die Person zusätzlich verifiziert, per Biometrie oder lokaler PIN. Nur UV macht aus dem Passkey einen Mehrfaktor-Nachweis im Sinne der NIST-Terminologie: Besitz des Geräts plus Wissen oder Biometrie. Wer eine Relying Party baut, muss diese Politik bewusst setzen und die Flags serverseitig prüfen – die Bibliothek tut es nicht automatisch richtig, wenn man userVerification: "preferred" konfiguriert und die Antwort dann nicht auswertet.

Der Signaturzähler (signCount) sollte laut Spezifikation bei jeder Nutzung steigen; der Server merkt sich den letzten Wert und kann bei einem Rückschritt auf einen geklonten Authenticator schließen. In der Passkey-Welt ist dieser Mechanismus allerdings weitgehend entwertet: Synchronisierte Credentials werden absichtlich auf mehrere Geräte kopiert, ein monotoner globaler Zähler ist dabei nicht sinnvoll führbar, und viele Plattform-Authenticatoren melden konstant Null. Ich bin der Meinung, dass man den Zähler daher heute als optionales Signal behandeln sollte: auswerten, wenn er ungleich Null ist, aber keine Sicherheitsarchitektur darauf bauen.

Teil 3: Von FIDO2 zu Passkeys – was sich geändert hat

Zwei Standards, ein System

FIDO2 ist der Sammelbegriff für zwei zusammengehörende Spezifikationen. WebAuthn regelt, wie Webanwendung und Browser miteinander sprechen. CTAP, das Client to Authenticator Protocol, regelt, wie der Browser mit einem externen Authenticator spricht – über USB (HID), NFC oder Bluetooth Low Energy. Wer nur Plattform-Authenticatoren benutzt, also Telefon oder Notebook mit eingebautem Schlüsselspeicher, sieht CTAP nie; wer Sicherheitsschlüssel einsetzt, hängt vollständig daran. CTAP wird von der FIDO Alliance gepflegt und hat sich seit der Fassung 2.0 vor allem um Unternehmensbedürfnisse erweitert: PIN-Verwaltung, Credential-Verwaltung auf dem Schlüssel, Enterprise Attestation.

Discoverable Credentials: der Anmeldename verschwindet

Der zweite technische Schritt hin zu Passkeys ist unscheinbar und in der Wirkung groß. Klassische FIDO2-Credentials waren non-discoverable: Der Server musste dem Browser eine Liste der Credential IDs schicken, die für dieses Konto in Frage kommen, und dazu musste der Nutzer zuerst seinen Namen eingeben. Discoverable Credentials – früher „Resident Keys" – speichern die Kontoinformation im Authenticator selbst. Der Server sagt nur noch „irgendein Credential für diese Domain, bitte", und der Client zeigt eine Auswahl der passenden Konten an. Damit fällt das Eingabefeld für den Benutzernamen weg, und die Anmeldung wird zu einem einzigen Schritt.

Genau diese Kombination – discoverable, plattformgestützt, komfortabel – bekam den Marketingnamen Passkey. Technisch ist ein Passkey nichts anderes als ein auffindbares WebAuthn-Credential.

Der eigentliche Bruch: synchronisierte Schlüssel

Der Punkt, an dem Passkeys sich vom klassischen FIDO2-Denken lösen, ist die Synchronisation. Ursprünglich war die Nichtexportierbarkeit des privaten Schlüssels das zentrale Versprechen: Der Schlüssel wird in Hardware erzeugt und verlässt sie niemals. Das ist maximal sicher und praktisch unzumutbar, denn es bedeutet: Gerät verloren, Zugang verloren – und deshalb braucht jeder einen zweiten Schlüssel, und deshalb machte es außerhalb von Hochsicherheitsumgebungen kaum jemand.

Die Antwort darauf sind Multi-Device Credentials, umgangssprachlich synchronisierte Passkeys. Der private Schlüssel wird Ende-zu-Ende-verschlüsselt in einem Sync-Dienst abgelegt – iCloud-Schlüsselbund, Google Password Manager, 1Password, Bitwarden – und auf die anderen Geräte desselben Nutzers verteilt. Der Verlust eines Geräts ist damit kein Ausschluss mehr.

Dieser Kompromiss ist genau die Antwort auf das Deployability-Problem aus der Bonneau-Matrix, und man sollte ehrlich benennen, was er kostet: Die Vertrauensgrenze verschiebt sich vom Stück Hardware auf das Plattformkonto und dessen Wiederherstellungsverfahren. Wer den Apple-, Google- oder Passwortmanager-Account übernimmt, übernimmt potenziell alle Passkeys. Die Phishing-Resistenz der einzelnen Anmeldung bleibt unangetastet – der Angriff verlagert sich eine Ebene nach oben.

Damit eine Relying Party diesen Unterschied überhaupt sehen kann, führte der Standard zwei Flags ein: BE (Backup Eligible) sagt, dass dieses Credential grundsätzlich synchronisierbar ist, und BS (Backup State), dass es aktuell gesichert ist. BE ist über die Lebensdauer des Credentials unveränderlich; BS kann wechseln. Ein Dienst, der AAL3 anstrebt, kann Credentials mit gesetztem BE-Flag ablehnen. Ein Consumer-Dienst wird sie begrüßen, weil sie seine Support-Kosten senken.

Cross-Device: warum QR-Code plus Bluetooth

Bleibt der Fall, dass man sich an einem fremden Rechner anmelden will, auf dem kein eigener Passkey liegt. Dafür definiert FIDO den hybriden Transport: Der Browser zeigt einen QR-Code, das Telefon scannt ihn, der eigentliche Anmeldevorgang läuft dann über einen verschlüsselten Tunnel, und das Telefon signiert.

Der sicherheitsrelevante Teil ist unauffällig und wichtig: Zusätzlich zum QR-Code wird eine Bluetooth-Low-Energy-Nachricht zum Nachweis der räumlichen Nähe verlangt. Ohne diese Anforderung wäre der QR-Code selbst phishbar – ein Angreifer könnte den Code seiner eigenen Sitzung auf einer Täuschungsseite anzeigen und sich vom Opfer die Anmeldung bestätigen lassen. Der Näheeinwurf macht Fernangriffe dieser Art wirkungslos, weil der Angreifer physisch im Raum stehen müsste. Man sieht hier gut, wie im Protokolldesign eine Bedrohungsanalyse zu einer Hardwareanforderung wird.

Teil 4: WebAuthn Level 3 – was der Standard 2026 kodifiziert

Am 25. August 2026 wurde Level 3 zur W3C-Recommendation; die FIDO Alliance kommentierte die Veröffentlichung Ende August. Der Charakter dieser Ausgabe ist typisch für einen reifenden Standard: Sie erfindet wenig und normiert viel, was die Browser längst ausliefern. Ein Überblick über die Neuerungen und ihre praktische Bedeutung:

Zwei Punkte verdienen Hervorhebung.

Related Origin Requests lösen ein Problem, das jede international aufgestellte Marke hat. Weil das RP-ID-Scoping – der eigentliche Phishing-Schutz – streng an eine Domain gebunden ist, war ein Passkey für marke.de auf marke.fr bisher unbrauchbar. ROR erlaubt es, an einer wohldefinierten Stelle eine Liste verwandter Origins zu veröffentlichen, die dieselben Credentials nutzen dürfen. Das ist eine bewusste, kontrollierte Lockerung des Scopings, und man sollte sie entsprechend behandeln: Diese Datei ist ein sicherheitskritisches Artefakt. Wer dort einen Eintrag unterschieben kann, weitet den Geltungsbereich fremder Schlüssel aus.

Die PRF-Extension ist die konzeptionell interessanteste Neuerung. Sie erlaubt es, aus einem Passkey eine pseudozufällige Funktion abzuleiten und damit reproduzierbar Schlüsselmaterial zu erzeugen, das an dieses Credential gebunden ist. Damit wird der Passkey nicht mehr nur Nachweis von Identität, sondern Quelle von Schlüsseln – die Grundlage für Anwendungen, die Daten clientseitig verschlüsseln und trotzdem auf mehreren Geräten lesbar halten wollen, ohne dass der Nutzer eine zweite Passphrase verwaltet. Wer schon einmal versucht hat, Ende-zu-Ende-Verschlüsselung in eine Webanwendung einzubauen, kennt die Stelle, an der es immer scheitert: Woher kommt der Schlüssel, und wie kommt er auf das zweite Gerät? PRF beantwortet diese Frage mit „aus der Anmeldung, über die Sync-Infrastruktur, die es sowieso schon gibt".

Teil 5: Wo Passkeys nicht schützen – die ehrliche Bilanz

Ein Artikel, der hier endet, wäre Werbung. Die interessanteren Fragen beginnen an den Rändern.

Der Downgrade-Angriff: der Notausgang ist die Angriffsfläche

Am 11. August 2025 beschrieb Proofpoint eine Angriffstechnik, die den Kern des Problems offenlegt. Sie greift WebAuthn nicht an – sie umgeht es. Der Angreifer betreibt wie üblich einen AiTM-Proxy, gibt sich aber gegenüber dem echten Dienst als Browser aus, der FIDO2 nicht unterstützt, indem er den User-Agent-String manipuliert. Der Dienst reagiert erwartungsgemäß und bietet dem Nutzer eine alternative Anmeldemethode an. Der Nutzer, der einen Fehler sieht und weiterkommen will, wählt die Authenticator-App. Ab diesem Moment ist es ein gewöhnlicher Phishing-Angriff mit gewöhnlichem Sitzungsdiebstahl.

Drei Dinge sind an diesem Befund wichtig. Erstens: Proofpoint hat diesen Angriff zum Zeitpunkt der Veröffentlichung nicht in der Praxis beobachtet – es handelt sich um eine demonstrierte, nicht um eine beobachtete Technik. Zweitens: Gegen Konten, die ausschließlich FIDO nutzen, funktioniert er nicht; gewöhnliche Phishing-Werkzeuge laufen dort schlicht auf einen Fehler. Drittens, und das ist die Lehre: Die Sicherheit eines Anmeldesystems ist die Sicherheit seiner schwächsten aktivierten Methode, nicht seiner stärksten. Wer Passkeys einführt und daneben SMS-Codes als Rückfallebene stehen lässt, hat die Bequemlichkeit verbessert und das Sicherheitsniveau nicht verändert.

Kontowiederherstellung: das eigentlich schwächste Glied

Dieselbe Logik gilt für die Wiederherstellung. Wenn ein Dienst Passkeys anbietet, aber bei Verlust des Geräts eine Rücksetzung per E-Mail-Link erlaubt, dann ist das Sicherheitsniveau des Kontos das des E-Mail-Postfachs. Das ist kein Implementierungsfehler, sondern eine Designentscheidung, die nur explizit getroffen werden kann: Entweder das Konto ist wiederherstellbar über einen schwächeren Kanal – dann existiert dieser Kanal auch für Angreifer –, oder es ist es nicht – dann gibt es Nutzer, die dauerhaft ausgeschlossen bleiben. Synchronisierte Passkeys entschärfen dieses Dilemma, indem sie den Geräteverlust seltener existenzbedrohend machen, aber sie beseitigen es nicht.

Der Endpunkt bleibt der Endpunkt

Passkeys schützen die Anmeldung, nicht die Sitzung. Läuft auf dem Rechner ein Infostealer, der das Sitzungscookie nach erfolgreicher Anmeldung ausliest, dann ist die Stärke des Anmeldeverfahrens irrelevant. Diebstahl von Sitzungstokens ist genau deshalb eine wachsende Angriffsklasse: Sie umgeht Authentifizierung vollständig, indem sie nach ihr ansetzt. Die Gegenmaßnahmen liegen auf einer anderen Ebene – Bindung von Tokens an das Gerät, kurze Lebensdauern, kontinuierliche Bewertung von Signalen –, und wer Passkeys für die Lösung dieser Klasse hält, missversteht ihren Geltungsbereich.

Die Nutzerseite: was die empirische Forschung zeigt

Sanam Ghorbani Lyastani, Michael Schilling, Michaela Neumayr, Michael Backes und Sven Bugiel legten 2020 auf dem 41. IEEE Symposium on Security and Privacy die erste große Laborstudie zu passwortloser FIDO2-Anmeldung vor, unter dem Titel Is FIDO2 the Kingslayer of User Authentication?. Das Ergebnis war zweigeteilt und ist bis heute lehrreich: Die Teilnehmer waren durchaus bereit, Sicherheitsschlüssel als direkten Passwortersatz zu akzeptieren – die Bedienung selbst war kein Hindernis. Die Bedenken entstanden an einer anderen Stelle, nämlich beim Wechsel der Faktorkategorie: von etwas, das man weiß, zu etwas, das man besitzt. Was, wenn ich es verliere? Was, wenn es kaputt geht? Wo ist mein Ersatz?

Diese Befunde erklären im Rückblick, warum die Branche den Weg über synchronisierte Passkeys gegangen ist und nicht über Hardware-Token für alle. Die Studie hat ein Akzeptanzhindernis identifiziert, und die Multi-Device Credentials sind, auf Protokollebene, die Antwort darauf. Das ist ein schönes Beispiel dafür, dass Usability-Forschung Standardentwicklung beeinflusst – und eine Erinnerung daran, dass die Sicherheitsfrage „ist der Schlüssel exportierbar?" und die Adoptionsfrage „traut sich der Nutzer das zu?" in entgegengesetzte Richtungen ziehen.

Privatsphäre und Verkettbarkeit

Weil für jede RP ID ein eigenes Schlüsselpaar entsteht, sind Passkeys über verschiedene Dienste hinweg nicht verkettbar: Zwei Dienste können anhand der öffentlichen Schlüssel nicht feststellen, dass sie denselben Nutzer sehen. Das ist ein echter Datenschutzgewinn gegenüber Federated-Login-Verfahren, bei denen ein Identitätsanbieter jede Anmeldung mitbekommt.

Die Attestation ist der Punkt, an dem das aufweichen kann. Eine AAGUID identifiziert kein Individuum, sondern einen Gerätetyp oder einen Credential-Manager – für sich genommen unkritisch, in Kombination mit anderen Merkmalen ein Fingerprinting-Beitrag. Der Standard war sich dessen immer bewusst und behandelt Attestation als etwas, das gezielt angefordert wird, nicht als Normalfall. Für Unternehmensumgebungen, die belegen müssen, dass nur verwaltete Hardware verwendet wird, ist Attestation unverzichtbar; für einen Consumer-Dienst ist attestation: "none" in der Regel die richtige und datensparsamere Wahl.

Teil 6: Passkeys in die Praxis bringen

Was die Relying Party speichern muss

Wer das selbst implementiert – und in C#, TypeScript oder Python gibt es dafür ausgereifte Bibliotheken, sodass man die Kryptographie nicht selbst schreiben sollte –, braucht pro Credential im Wesentlichen diese Felder:

Die wiederkehrenden Implementierungsfehler sind erstaunlich konstant: Challenges werden nicht serverseitig gespeichert und damit nicht wirklich auf Einmaligkeit geprüft; das Feld origin wird gar nicht ausgewertet; userVerification: "required" wird angefordert, aber das UV-Flag in der Antwort ignoriert; und die erwartete RP ID wird aus dem Request abgeleitet statt fest konfiguriert. Jeder einzelne dieser Fehler hebt genau den Schutz auf, um dessentwillen man das Verfahren eingeführt hat.

Vier Entscheidungen, die man bewusst treffen muss

1. User Verification: required macht den Passkey zum Mehrfaktor-Nachweis und ist für alles, was nach AAL2 aussieht, die richtige Wahl. preferred ist bequemer und liefert unter Umständen nur Besitznachweis.
2. Attestation: none für Consumer, direct oder Enterprise Attestation dort, wo verwaltete Hardware nachgewiesen werden muss.
3. Synchronisierte Credentials erlauben? Für Endkundendienste ja, weil sie die Adoption tragen. Für Systeme mit AAL3-Anspruch nein – SP 800-63B-4 schließt exportierbare private Schlüssel dort aus.
4. Rückfallebene: die wichtigste und meistübergangene Entscheidung. Ein zweiter Passkey auf einem anderen Gerät ist eine gute Rückfallebene. Ein SMS-Code ist keine, sondern die Aufhebung des Verfahrens.

Migration ohne Bruch

Der praktikable Weg zur Einführung nutzt genau die Level-3-Funktionen aus Teil 4. Conditional Get bringt Passkeys in die bestehende Anmeldemaske, ohne sie umzubauen. Conditional Create legt nach einer erfolgreichen Passwortanmeldung still einen Passkey an, sodass der Bestand wächst, ohne dass jemand einen Assistenten durchklicken muss. Die Signals API hält das Kontoverzeichnis und den Credential-Manager im Gleichlauf, damit gelöschte Konten keine verwaisten Einträge hinterlassen. Und erst, wenn ein Konto zwei unabhängige Passkeys hat, ist es sinnvoll, das Passwort für dieses Konto tatsächlich zu deaktivieren – nicht vorher.

Der Blick auf die Regulierung

Für europäische Kontexte lohnt eine Abgrenzung, die oft verschwimmt. Passkeys sind ein Authentifizierungsverfahren: Sie beweisen, dass derselbe Schlüsselinhaber wie bei der Registrierung anwesend ist. Sie sagen nichts darüber, wer das ist. Verfahren rund um eIDAS 2.0 und die EU-Identitäts-Wallet lösen die andere Hälfte des Problems: verifizierte Identitätsattribute mit selektiver Offenlegung. Die beiden schließen sich nicht aus, sie greifen ineinander – ein Wallet braucht selbst eine phishing-resistente Anmeldung, und ein Dienst, der Alter oder Wohnsitz belegt haben muss, kommt mit einem Passkey allein nicht weiter. Wer Anforderungen liest, sollte die Frage „welcher Schlüssel?" von der Frage „welche Person?" getrennt halten.

Teil 7: Das übergeordnete Denkprinzip

Wenn man einen Schritt zurücktritt, ist die Geschichte der Passkeys ein Lehrstück über eine bestimmte Art, Sicherheitsprobleme zu lösen. Dreißig Jahre lang wurde Phishing als Verhaltensproblem behandelt: Schulungen, Warnhinweise, simulierte Angriffe, grüne Adressleisten. Der Erfolg war bescheiden, weil man Menschen bat, eine Aufgabe zuverlässig zu erledigen, für die sie nicht gebaut sind – das Prüfen von Zeichenketten unter Zeitdruck.

WebAuthn behandelt dasselbe Problem als Protokollproblem und verschiebt die Aufgabe dorthin, wo sie gut lösbar ist: Der Browser weiß mit Sicherheit, auf welcher Domain er ist. Diese Gewissheit wird in die Signatur hineingezogen, und damit verschwindet die Entscheidung, die der Mensch nicht treffen kann, aus dem Ablauf.

Dieses Muster – eine Sicherheitseigenschaft nicht erbitten, sondern strukturell erzwingen – begegnet einem in der Informatik immer wieder. Typsysteme machen eine Klasse von Fehlern nicht unwahrscheinlicher, sondern unausdrückbar. Speichersichere Sprachen ersetzen Disziplin durch Garantie. Kapazitätsbasierte Sicherheitsmodelle ersetzen Zugriffslisten durch unfälschbare Referenzen. Und in der Kryptographie ist es immer wieder die Bindung an einen Kontext, die einen Beweis unübertragbar macht.

Erkenntnis zum Mitnehmen

Die praktische Lehre lautet: Die Phishing-Resistenz eines Passkeys steckt nicht in der Biometrie und nicht im Wegfall des Eingabefelds, sondern in einem einzigen signierten Feld, das der Browser setzt und der Server prüfen muss – und sie ist genau so stark wie die schwächste Anmeldemethode, die daneben aktiviert bleibt.

Daraus folgen vier Schritte, die man in jedem Projekt gehen kann. Erstens: Inventarisiere alle aktivierten Anmelde- und Wiederherstellungswege für privilegierte Konten und schreibe zu jedem hin, ob er phishbar ist – diese Liste, nicht die Existenz von Passkeys, beschreibt das tatsächliche Sicherheitsniveau. Zweitens: Prüfe in der eigenen Implementierung explizit vier Dinge – Einmaligkeit der Challenge, origin, RP ID gegen eine feste Konfiguration, und das UV-Flag in der Antwort. Drittens: Entscheide bewusst, ob synchronisierte Credentials erlaubt sind, und leite die Entscheidung aus der geforderten Assurance ab, nicht aus dem Bauch – die BE- und BS-Flags machen sie überhaupt erst durchsetzbar. Viertens: Deaktiviere das Passwort eines Kontos erst, wenn zwei unabhängige Passkeys registriert sind, und nutze Conditional Create, um dorthin zu kommen, ohne Nutzer durch einen Assistenten zu schicken.

Eine Frage zum Nachdenken

Synchronisierte Passkeys haben ein Sicherheitsversprechen gegen ein Adoptionsversprechen getauscht: Der private Schlüssel ist nicht mehr unexportierbar, dafür benutzt ihn eine Milliardenzahl von Menschen. Gemessen am Gesamtschaden ist das mit hoher Wahrscheinlichkeit der richtige Tausch – ein mittelmäßig geschützter Schlüssel, den alle nutzen, verhindert mehr Kontoübernahmen als ein perfekt geschützter, den niemand hat.

Die Frage, die daraus folgt, ist unbequemer, als sie klingt: Diese Rechnung verlagert das Restrisiko von den vielen auf die wenigen, deren Konten Angreifer einzeln und gezielt attackieren – und sie bindet die Sicherheit fast aller Anmeldungen an eine Handvoll Sync-Anbieter. Wer in deiner Organisation hat eigentlich entschieden, welche Konten in die erste und welche in die zweite Kategorie gehören? Denn erfahrungsgemäß wird diese Entscheidung nicht in einem Risikoworkshop getroffen. Sie wird implizit getroffen, in dem Moment, in dem jemand für alle Nutzergruppen dieselbe Authentifizierungsrichtlinie aktiviert.

Querverweise im Vault

• Der Schlüssel, der nach jeder Nachricht stirbt: Das Signal-Protokoll, die Double Ratchet und die Kunst der Ende-zu-Ende-Verschlüsselung – asymmetrische Kryptographie im Dienst derselben Idee: Schlüssel, die nie übertragen werden, und Sicherheit durch Bindung statt durch Geheimhaltung allein.
• Der Ausweis, der schweigt: eIDAS 2.0, die EU-Identitäts-Wallet und die Kunst, nur das Nötigste preiszugeben – die andere Hälfte des Problems: Passkeys beweisen Kontinuität, Wallets beweisen Identitätsattribute.
• Beweisen ohne zu verraten: Zero-Knowledge-Beweise von Ali Babas Höhle bis zu zk-SNARKs – die Radikalisierung desselben Prinzips: einen Beweis erbringen, ohne das Geheimnis zu zeigen.
• Ernte jetzt, entschlüssle später: Post-Quanten-Kryptographie und das Rennen gegen den Quantencomputer – warum die Signaturalgorithmen hinter WebAuthn eine begrenzte Haltbarkeit haben und Algorithmus-Agilität im Datenmodell vorgesehen sein sollte.
• Die Hintertür im Herzen von Linux: Der XZ-Backdoor und die Anatomie eines Supply-Chain-Angriffs – der Angriff, der an der Authentifizierung vorbeigeht, indem er die Vertrauenskette darunter verändert.
• Bits, die von selbst umkippen: Rowhammer und die physikalische Schwachstelle des Arbeitsspeichers – Erinnerung daran, dass „der Schlüssel verlässt die Hardware nicht" eine Aussage über Hardware ist, die selbst angreifbar bleibt.
• Wenn der Prozessor zu viel rät: Spectre, Meltdown und die Sünde der spekulativen Ausführung – dieselbe Lektion auf der Ebene des Prozessors: Sicherheit, die auf einer Abstraktion beruht, endet dort, wo die Abstraktion undicht ist.

Quellen

• W3C (2026): Web Authentication: An API for accessing Public Key Credentials – Level 3. W3C Recommendation, 25. August 2026. Editoren: T. Cappalli, A. Kumar, E. Lundberg, M. Miller, Pascoe, N. Satragno. https://www.w3.org/TR/webauthn-3/
• FIDO Alliance (2026): WebAuthn Level 3 Is Now a W3C Recommendation. 31. August 2026. https://fidoalliance.org/webauthn-level-3-is-now-a-w3c-recommendation/
• National Institute of Standards and Technology (2025): Digital Identity Guidelines – Authentication and Authenticator Management. NIST Special Publication 800-63B-4, Teil der Suite NIST SP 800-63-4, veröffentlicht August 2025. DOI: 10.6028/NIST.SP.800-63-4. https://pages.nist.gov/800-63-4/sp800-63b.html
• Lyastani, S. G., Schilling, M., Neumayr, M., Backes, M., Bugiel, S. (2020): Is FIDO2 the Kingslayer of User Authentication? A Comparative Usability Study of FIDO2 Passwordless Authentication. 41st IEEE Symposium on Security and Privacy (SP '20). https://publications.cispa.saarland/3146/
• Bonneau, J., Herley, C., van Oorschot, P. C., Stajano, F. (2012): The Quest to Replace Passwords: A Framework for Comparative Evaluation of Web Authentication Schemes. IEEE Symposium on Security and Privacy 2012, S. 553–567. DOI: 10.1109/SP.2012.44. https://www.cl.cam.ac.uk/~fms27/papers/2012-BonneauHerOorSta-password--oakland.pdf
• Proofpoint (2025): Don't Phish-let Me Down: FIDO Authentication Downgrade. Threat Insight, 11. August 2025. https://www.proofpoint.com/us/blog/threat-insight/dont-phish-let-me-down-fido-authentication-downgrade
• Jakkal, V., Abdo, N. (2026): World Passkey Day: Advancing passwordless authentication. Microsoft Security Blog, 7. Mai 2026. https://www.microsoft.com/en-us/security/blog/2026/05/07/world-passkey-day-advancing-passwordless-authentication/

← All articles