Zu den veröffentlichten Techniken zählen unter anderem Assertion Mining, Assertion Replay, Circuit-Breaker-Angriffe, Assertion-Phishing, Browser-Hooking, das Abgreifen von Assertions, Challenge Injection, Detour Replay sowie die Manipulation von Nutzerverifikation und Nutzerpräsenz.
Wie folgenreich das ist, hat SpecterOps mit seiner Forschung „Pass the Passkey" gezeigt. Die zentrale Beobachtung: Schadsoftware muss den privaten Schlüssel gar nicht extrahieren. Eine bösartige Windows-Anwendung kann die legitime WebAuthn-Infrastruktur dazu bringen, eine signierte Assertion zu erzeugen. Der Nutzer sieht eine scheinbar reguläre Windows-Anmeldung, bestätigt die Verifikation – und der Angreifer erhält die Assertion. Der private Schlüssel hat seinen geschützten Speicherort nie verlassen, geknackt wurde nichts, manipuliert wurde der Ablauf.
Eine ganze Reihe der 39 Techniken zielt auf die Benutzeroberfläche rund um die Anmeldung: Fluten mit Passkey-Aufforderungen, Täuschung über die Anmeldeoberfläche, gefälschte Anwendungs-Metadaten, Spoofing von Fensterkennungen, Passkey-Phishing über Remote-Desktop-Sitzungen und Overlay-Angriffe auf FIDO-Oberflächen. Das wiederholt ein Problem, das die Branche von push-basierter Mehrfaktor-Authentifizierung kennt: Sobald Anmeldebestätigungen zur Routine werden, lassen sie sich erzeugen, wiederholen, tarnen oder gezielt zeitlich platzieren. SpecterOps demonstrierte Werkzeuge, die wiederholt legitim wirkende Windows-Passkey-Dialoge auslösen; andere Forschung zeigt, wie sich bösartige Anmeldeaktivität so darstellen lässt, als käme sie von einer Anwendung, der die Beschäftigten bereits vertrauen. Phishing-Resistenz auf der Protokollebene garantiert eben keine Täuschungsresistenz auf den Ebenen darüber.
Deutlich größer wird die Angriffsfläche, sobald Passkeys geteilt, synchronisiert, exportiert, wiederhergestellt oder zwischen Geräten bewegt werden können. Die Liste umfasst kompromittierte synchronisierte Tresore, Übernahmen von Apple- oder Google-Konten, Übernahme der Cloud-Wiederherstellung, gestohlene oder kompromittierte Telefone, mobile Schadsoftware, gerootete Geräte, Manipulation der hybriden Authentifizierung, Export-Diebstahl bei KeePassXC und Bitwarden, Diebstahl beim Credential Exchange, bösartige Browser-Erweiterungen sowie Angriffe auf CTAP- und Bluetooth-Kommunikation. Das ist im Kern kein Kryptografie-, sondern ein Architekturproblem: Ein synchronisierter Passkey erbt die Schwächen von Telefon, Betriebssystem, Passwortmanager, Cloud-Konto, Browser, Wiederherstellungs- und Synchronisierungsprozess.
Besonders folgenreich sind Angriffe, die gar keinen bestehenden Passkey stehlen, sondern einen zusätzlichen anlegen: Shadow-Passkeys, Enrollment-Vishing, Registrierung des Angreifertelefons, angreiferkontrollierte Passkey-Registrierung, Helpdesk-Übernahme, Missbrauch temporärer Zugangsdaten, SIM-basierte Wiederherstellung, Reverse Vishing und Vorwandangriffe rund um Gerätemigration. Erlangt ein Angreifer genug Kontrolle über ein Konto, um eine reguläre Passkey-Registrierung anzustoßen, stellt der legitime Dienst selbst einen gültigen Berechtigungsnachweis für den Angreifer aus. Daraus folgt ein Grundsatz: Phishing-resistente Authentifizierung genügt nicht, wenn Registrierung, Ersatz, Wiederherstellung und Geräteanmeldung nicht demselben Maßstab unterliegen.
Dedizierte Biometrie-Hardware setzt laut Token an dieser Stelle an: Der Berechtigungsnachweis verbleibt in sicherer Hardware, ohne Cloud-Synchronisierung, ohne Exportfunktion, ohne Passwortmanager. Die Anmeldung verlangt einen Fingerabdruck direkt am Authentifikator und physische Nähe zum Endgerät. Da ein solches Gerät kein universelles Betriebssystem, keinen App-Store, keinen Browser und keinen Bildschirm besitzt, entfallen große Teile der Angriffsfläche – es gibt keine Anwendungen zum Austauschen, kein Erweiterungs-Ökosystem und keine Anzeige, auf der Schadsoftware eine täuschende Oberfläche zeigen könnte.
Hardware allein reicht jedoch nicht. Der Dienst muss Authentifizierung und Registrierung auf zugelassene Authentifikator-Klassen beschränken, die Identität des Authentifikators prüfen, Nutzerverifikation erzwingen, Challenges und Sitzungen validieren, Signaturzähler absichern und schwächere Verfahren als Rückfallweg ausschließen. Ein neuer Authentifikator sollte nur mit Nachweis über einen bereits autorisierten Authentifikator hinzugefügt werden – nicht über einen schwächeren Wiederherstellungskanal.
Die 39 veröffentlichten Methoden zeigen laut Token nicht das Versagen der FIDO2-Kryptografie, sondern das Gegenteil: Angegriffen werden Software, Synchronisierung, Registrierung, Betriebssysteme, Browser, Wiederherstellung und Menschen, weil korrekt implementierte kryptografische Hardware direkt anzugreifen erheblich schwieriger ist.