Die Sicherheitsversprechen der Passkey-Authentifizierung schienen zunächst bahnbrechend: Ende-zu-Ende-Verschlüsselung durch Public-Key-Kryptografie, private Schlüssel, die niemals den Server verlassen, und ein effektiver Schutz vor Phishing-Angriffen. Doch die Realität der Bedrohungslandschaft hat sich rasant verändert – inzwischen sind mindestens 39 öffentlich dokumentierte Methoden bekannt, die diese Authentifizierung kompromittieren können, ohne dass die zugrundeliegende Kryptografie gebrochen werden muss.
Das Ziel ist nicht mehr nur der Passkey
Eine moderne Passkey-Authentifizierung durchläuft eine beeindruckende Anzahl von Vertrauensgrenzen: die Webanwendung, den Browser, das Betriebssystem, den Passwortmanager, den Cloud-Synchronisationsdienst, das mobile Endgerät, die Bluetooth-Übertragung, das Account-Recovery-System, den Enrollment-Prozess, den Helpdesk und letztlich den Menschen, der die Authentifizierung freigibt. Forscher attackieren mittlerweile nahezu jede dieser Ebenen. Zu den publizierten Techniken zählen unter anderem Assertion Mining, Assertion Replay, Browser-Hooking, Challenge Injection, Detour Replay, User-Verification-Manipulation und User-Presence-Manipulation.
Die Forschungsarbeit „Pass the Passkey“ von SpecterOps verdeutlicht die Tragweite dieses Problems. Eine der zentralen Erkenntnisse: Malware muss nicht zwingend einen privaten Schlüssel extrahieren. Eine schadhafte Windows-Anwendung kann die legitime WebAuthn-Infrastruktur auffordern, eine signierte Assertion zu generieren. Der Nutzer sieht eine vermeintlich vertrauenswürdige Windows-Authentifizierungsoberfläche, schließt die Verifikation ab – und der Angreifer erhält die daraus resultierende Assertion. Der private Schlüssel verließ nie seinen geschützten Ort. Die Kryptografie wurde nicht geknackt. Dennoch wurde der gesamte Authentifizierungsprozess erfolgreich manipuliert. Diese Unterscheidung ist zentral für das Verständnis des neuen Passkey-Bedrohungsmodells.
Sogar die Passkey-Aufforderung ist eine Angriffsfläche
Mehrere der 39 dokumentierten Techniken zielen direkt auf die Benutzeroberfläche rund um die Authentifizierung ab. Forscher haben unter anderem Passkey-Prompt-Flooding, Credential-Interface-Deception, Application-Metadata-Spoofing, Window-Handle-Spoofing, Remote-Desktop-Passkey-Phishing und FIDO-Interface-Overlay-Angriffe demonstriert. Dies reproduziert ein Problem, das die Sicherheitsbranche bereits von der push-basierten Multi-Faktor-Authentifizierung kennt: Nutzer gewöhnen sich an Authentifizierungsaufforderungen. Wird die Authentifizierung zu einer routinemäßigen visuellen Interaktion, können Angreifer diese Interaktionen herstellen, wiederholen, tarnen oder strategisch timen. Die Phishing-Resistenz auf der kryptografischen Protokollebene garantiert keine Täuschungsresistenz auf den darüberliegenden Schichten des Betriebssystems, des Browsers, der Anwendung und der Benutzeroberfläche.
Teilbare Passkeys erweitern die Angriffsfläche massiv
Das Angriffspotenzial wächst signifikant, sobald Passkeys geteilt, synchronisiert, exportiert, wiederhergestellt oder zwischen Geräten verschoben werden können. Die öffentlich bekannte Liste umfasst nun Techniken wie die Kompromittierung synchronisierter Vaults, die Übernahme von Apple- oder Google-Konten, Cloud-Recovery-Übernahmen, den Diebstahl oder die Kompromittierung von Mobiltelefonen, mobile Malware, gerootete Geräte, die Manipulation hybrider Authentifizierung, den Diebstahl von KeePassXC- oder Bitwarden-Exporten, bösartige Browsererweiterungen sowie Angriffe auf CTAP- und Bluetooth-Kommunikation.
Dies ist im Kern kein kryptografisches Problem, sondern ein architektonisches. Sobald ein Credential zwischen Geräten wechseln, über ein Cloud-Konto synchronisiert, aus einem Vault exportiert, mit einer anderen Identität wiederhergestellt oder über einen anderen Prozess zurückgesetzt werden kann, erstreckt sich die Sicherheitsgrenze weit über den ursprünglichen Authenticator hinaus. Ein Angreifer muss FIDO2 nicht mehr besiegen – er muss lediglich eine ausreichend vertrauenswürdige Komponente im umgebenden Ökosystem kompromittieren. Ein synchronisierter Passkey kann daher extrem starke Kryptografie nutzen und dennoch die Schwächen des Telefons, des Betriebssystems, des Passwortmanagers, des Cloud-Kontos, des Browsers, des Recovery-Prozesses und des Synchronisationssystems erben, die für seine Verwaltung verantwortlich sind.
Enrollment und Recovery schaffen eine weitere Einfallstür
Einige der folgenreichsten Angriffe stehlen gar keinen existierenden Passkey. Sie registrieren einfach einen neuen. Zu den publizierten Techniken gehören Shadow Passkeys, Enrollment-Vishing, die Registrierung eines Angreifer-Telefons, die kontrollierte Passkey-Registrierung durch den Angreifer, Helpdesk-Übernahmen, der Missbrauch temporärer Credentials, SIM-basiertes Recovery, Reverse-Vishing und Migration-Pretext-Angriffe.
Stellen Sie sich vor, ein Angreifer erlangt die Kontrolle über ein Mitarbeiterkonto, das ausreicht, um eine legitime Passkey-Registrierung zu initiieren. Statt das bestehende Credential des Mitarbeiters zu extrahieren, registriert der Angreifer ein völlig neues Credential auf einem von ihm kontrollierten Gerät. Nichts wurde geknackt. Nichts wurde vom legitimen Authenticator gestohlen. Der legitime Dienst selbst erstellt ein perfekt gültiges Credential für den Widersacher. Dies führt zu einem zunehmend wichtigen Identitätsprinzip: Phishing-resistente Authentifizierung ist unzureichend, wenn Enrollment, Ersatz, Recovery und Geräteregistrierung nicht demselben Standard entsprechen.
Dedizierte biometrische Hardware verändert die Angriffsfläche grundlegend
Dedizierte biometrische Hardware nähert sich dem Problem fundamental anders als Passkeys auf Allzweckgeräten. Ein speziell für diesen Zweck entwickelter biometrischer Authenticator kann das private Credential in sicherer Hardware speichern – ohne Cloud-Synchronisation, ohne Exportmechanismus und ohne Passwortmanager, der das Credential zwischen Geräten bewegt. Die Authentifizierung kann sowohl einen Live-Fingerabdruck direkt auf dem Authenticator als auch die physische Nähe zum anfragenden Endpunkt erfordern. Ein dedizierter Authenticator benötigt zudem kein herkömmliches Allzweck-Betriebssystem, keinen App-Store, keinen Browser und keinen Bildschirm.
Diese Unterscheidung eliminiert enorme Teile der Angriffsfläche. Es gibt keine Drittanbieter-Anwendungen, die ein Angreifer durch schadhafte Versionen ersetzen könnte. Auf dem Authenticator können keine schädlichen Apps installiert werden. Es gibt kein Browser-Erweiterungs-Ökosystem, das kompromittiert werden könnte. Es gibt keinen Bildschirm, auf dem Malware eine trügerische Authentifizierungsoberfläche präsentieren könnte. Der Authenticator führt eine sehr kleine Anzahl sicherheitsspezifischer Funktionen aus – und sonst nichts. Dies verändert die Ökonomie eines Angriffs drastisch. Statt eine riesige Allzweck-Computerumgebung zu kompromittieren, steht der Angreifer einer eng kontrollierten Hardware gegenüber, die speziell dafür entwickelt wurde, kryptografische Credentials zu schützen und die biometrische Identität zu verifizieren.
Gleichzeitig wird der Authentifizierungsprozess weitaus resistenter gegen Manipulation durch Mitarbeiter. Ein Mitarbeiter kann überredet werden, eine Website zu besuchen, einen Telefonanruf zu beantworten oder Anweisungen eines angeblichen Support-Mitarbeiters zu befolgen. Social Engineering kann jedoch keine schädliche Anwendung auf Hardware installieren, die keine gewöhnlichen Anwendungen ausführt. Es kann einen nicht existierenden Bildschirm nicht manipulieren. Es kann kein Credential durch einen Cloud-Dienst synchronisieren, den der Authenticator nicht nutzt. Eine richtig konzipierte dedizierte biometrische Hardware wird dadurch sowohl resistent gegen Angreifer als auch gegen Fehler von Mitarbeitern.
Die korrekte Dienstkonfiguration ist entscheidend
Dedizierte Hardware allein reicht nicht aus. Der relying Service muss so konfiguriert sein, dass das Sicherheitsmodell erhalten bleibt. Für sensible Unternehmensumgebungen sollten Authentifizierung und Enrollment auf zugelassene Authenticator-Klassen beschränkt werden. Die relying Party sollte die Authenticator-Identität validieren, die Benutzerverifikation erzwingen, Challenges und Sessions ordnungsgemäß validieren, angemessene Signaturzähler-Schutzmaßnahmen verwenden und verhindern, dass schwächere Methoden zu fallback-Authentifizierungspfaden werden. Enrollment und Recovery verdienen besondere Aufmerksamkeit: Das Hinzufügen eines neuen Authenticators sollte den Nachweis durch einen bereits autorisierten Authenticator erfordern – und nicht lediglich den Nachweis der Kontrolle über ein Konto durch einen schwächeren Recovery-Kanal.
Was die 39 Angriffsmethoden wirklich bedeuten
Die Existenz von 39 publizierten Angriffsmethoden bedeutet nicht, dass die FIDO2-Kryptografie versagt hat. In vielerlei Hinsicht zeigt sie das Gegenteil. Forscher attackieren wiederholt die Software, die Synchronisationssysteme, die Enrollment-Prozesse, die Betriebssysteme, die Browser, die Recovery-Mechanismen und die Menschen, die das Credential umgeben – weil es erheblich schwieriger ist, eine korrekt implementierte kryptografische Hardware direkt zu besiegen. Das sollte Sicherheitsverantwortlichen zeigen, wo die nächste Identitätsgrenze gezogen werden muss. Für hochwertige Unternehmensidentitäten sollten Credentials nicht frei über Consumer-Geräte und Cloud-Ökosysteme teilbar sein. Sie sollten an dedizierte biometrische Hardware, die verifizierte Person, den legitimen Dienst und einen unternehmenskontrollierten Enrollment- und Recovery-Prozess gebunden sein. Die 39 publizierten Angriffe zeigen uns, was Angreifer anvisieren. Dedizierte biometrische Hardware, korrekt implementiert vom Enrollment über die Authentifizierung bis zum Recovery, entfernt praktisch die gesamte umgebende Angriffsfläche – bevor ein Angreifer überhaupt die Gelegenheit erhält, sie zu nutzen.
