Pass-ta-key: Was der Angriff auf Google-Passkeys wirklich bedeutet

Sind Passkeys jetzt doch unsicher? Genau diese Frage wirft Pass-ta-key auf.

Palo Alto Networks Unit 42 beschreibt drei Angriffsketten, mit denen Malware Google-synchronisierte Passkeys missbrauchen, die Benutzerverifikation umgehen und im schwersten Szenario sämtliche privaten Passkey-Schlüssel eines Kontos extrahieren kann.

Keine der drei Techniken bricht WebAuthn, FIDO2 oder die verwendete Public-Key-Kryptografie. Alle setzen voraus, dass bereits Malware auf dem Windows-PC des Opfers läuft. Das ist eine erhebliche Einschränkung.

Trotzdem ist „auf einem kompromittierten Endpoint ist ohnehin alles verloren“ als Analyse zu bequem. Die Golden-Pass-ta-key-Variante soll aus einem lokalen Einbruch ein dauerhaft nutzbares, exportierbares Paket aller synchronisierten Passkeys machen. Damit geht die Wirkung über den Diebstahl einer einzelnen Browsersitzung hinaus.

Die kurze Einschätzung vorweg

Ja, das ist ein neues und eigenständiges Security-Thema. Es ist aber kein Grund, Passkeys abzuschaffen oder wieder ausschliesslich auf Passwörter zu setzen.

Die richtige Einordnung lautet:

• Das Protokoll hält: Origin Binding, Challenge-Response und die asymmetrische Kryptografie werden nicht gebrochen.
• Die konkrete Implementierung wird angegriffen: Betroffen ist die von Unit 42 untersuchte Kombination aus Google Password Manager, Chrome, Windows und einem TPM.
• Der Endpoint muss bereits kompromittiert sein: Es handelt sich nicht um einen Angriff, den eine beliebige Website aus dem Internet gegen einen sauberen Rechner ausführen kann.
• Der mögliche Schaden ist trotzdem erheblich: Die Varianten reichen von einer still erzeugten Login-Assertion bis zur Extraktion der privaten Schlüssel aller synchronisierten Passkeys.
• Synchronisierte und gerätegebundene Passkeys haben unterschiedliche Risikoprofile: Beides sind Passkeys, aber nicht dieselbe Sicherheitsstufe.
• Passwörter bleiben die schlechtere Alternative: Sie können zusätzlich gephisht, wiederverwendet, erraten und aus Serverdatenbanken gestohlen werden.

Meine Risikobewertung ist deshalb nicht „nichts passiert“, sondern: enge technische Reichweite und anspruchsvolle Vorbedingung, bei erfolgreicher Ausführung aber potenziell sehr hohe Auswirkung.

Technischer Scope und Evidenz

Der belegte Stand zum 31. August 2026 umfasst die von Unit 42 dokumentierten Angriffsabläufe, die WebAuthn-Spezifikation, Googles Passkey-Dokumentation, den öffentlich sichtbaren Chromium-Issue und die aktuellen NIST-Vorgaben für synchronisierbare Authentikatoren. Ergänzend gehören Pass-the-Passkey von SpecterOps, CVE-2026-34348, Proofpoints FIDO-Downgrade sowie die technischen Erkenntnisse von Expel und SquareX zur Bewertung der Angriffsfläche.

Die Forschung wurde am 3. August veröffentlicht und von Unit 42 am 14. August aktualisiert. Sie bezieht sich ausdrücklich auf Google Password Manager in Chrome unter Windows, auf Geräten mit Trusted Platform Module. Andere Browser, Betriebssysteme und Passkey-Provider können ähnliche Architekturfragen haben, wurden mit diesen drei Angriffen aber nicht nachgewiesen.

Für diese spezifischen Techniken ist keine aktive Angriffskampagne in freier Wildbahn dokumentiert. Der aktuelle Evidenzstand besteht aus Forschung, Proofs of Concept und Responsible Disclosure. Das ist für die Risikobewertung wichtig: technisch demonstriert bedeutet nicht automatisch bereits massenhaft ausgenutzt.

Was ein Passkey eigentlich schützt

Ein Passkey ist kein besonders langes Passwort. Er ist ein WebAuthn-Zugangsschlüssel auf Basis asymmetrischer Kryptografie.

Bei der Registrierung erzeugt der Authentikator ein Schlüsselpaar:

privater Schlüssel  -> bleibt beim Authentikator
öffentlicher Schlüssel -> wird beim Onlinedienst registriert

Der Onlinedienst, in WebAuthn „Relying Party“ genannt, speichert den öffentlichen Schlüssel zusammen mit einer Credential-ID und dem Benutzerkonto. Beim späteren Login sendet der Dienst eine neue, zufällige Challenge. Der Authentikator signiert Daten, die unter anderem diese Challenge und den Kontext der aufrufenden Website binden. Der Server prüft die Signatur mit dem hinterlegten öffentlichen Schlüssel.

Der private Schlüssel wird also nicht wie ein Passwort an den Server übertragen. Ein Datenleck beim Dienst liefert einem Angreifer im Idealfall nur öffentliche Schlüssel. Damit kann er keine gültigen Signaturen erzeugen.

Entscheidend ist ausserdem die Bindung an die Relying-Party-ID und den Web-Origin. Ein Passkey für example.com erzeugt auf einer täuschend ähnlichen Phishing-Domain keine für example.com gültige Assertion. Der Benutzer hat kein Geheimnis, das er auf der falschen Website eintippen oder einem Angreifer am Telefon vorlesen kann.

Genau das bedeutet phishing-resistent. NIST definiert diesen Begriff eng: Ein betrügerischer Verifier darf weder das Authentisierungsgeheimnis noch eine beim echten Dienst verwendbare Authentisierungsantwort erhalten. WebAuthn erreicht dies über die kryptografische Bindung an den Namen des Verifiers.

Diese Eigenschaft bleibt bei Pass-ta-key intakt. Die Malware baut keine bessere Phishing-Seite. Sie läuft bereits auf dem Gerät, das der Benutzer als vertrauenswürdigen Authentikator verwendet.

User Presence und User Verification sind nicht dasselbe

Für die drei Angriffe muss man zwei WebAuthn-Signale unterscheiden:

• User Presence, UP: Ein Benutzer hat eine Anwesenheitsaktion ausgelöst, etwa einen Security Key berührt oder einen Dialog bestätigt.
• User Verification, UV: Der Authentikator hat den Benutzer lokal verifiziert, beispielsweise über Windows Hello, PIN oder Biometrie.

Die WebAuthn-Assertion enthält diese Resultate als Flags in den authenticatorData. Der Server darf nicht nur darauf vertrauen, was er beim Start des Logins angefordert hat. Wenn er userVerification: "required" verlangt, muss er bei der Antwort auch prüfen, ob das UV-Flag tatsächlich gesetzt ist.

Dieser einzelne Kontrollpunkt ist wichtig. Unit 42 konnte den einfachen Pass-ta-key-Angriff gegen GitHub nicht erfolgreich abschliessen, weil die notwendige User Verification fehlte. Bei eBay gelang der Login zunächst trotzdem, obwohl User Verification angefordert worden war. eBay korrigierte die serverseitige Prüfung nach der Meldung.

Der Unterschied zeigt: Eine kryptografisch korrekte Signatur reicht nicht immer für eine korrekt implementierte Multi-Faktor-Authentisierung. Die Relying Party muss zusätzlich validieren, welche Sicherheitsbedingungen der Authentikator tatsächlich bestätigt hat.

Warum synchronisierte Passkeys einen zusätzlichen Vertrauensbereich schaffen

Ein gerätegebundener Passkey bleibt auf einem bestimmten Authentikator, etwa einem Hardware Security Key oder einem lokal geschützten Plattform-Authentikator. Ein synchronisierter Passkey soll dagegen auf mehreren Geräten verfügbar sein. Dafür muss sein privates Schlüsselmaterial in verschlüsselter Form gesichert, über eine Sync-Infrastruktur transportiert und auf anderen autorisierten Geräten wiederhergestellt werden können.

Das ist kein kleiner Implementierungsunterschied. Synchronisierung erweitert das System:

Relying Party
    |
Browser und WebAuthn-Client
    |
lokaler Plattform-Authentikator
    |
Passkey-Manager und Recovery-Logik
    |
Cloud-Sync und weitere Geräte

Jede zusätzliche Ebene braucht eigene Regeln für Gerätevertrauen, Onboarding, Recovery, Schlüsselverschlüsselung und Widerruf.

NIST behandelt synchronisierbare Authentikatoren deshalb ausdrücklich als eigene Kategorie. Sie können für Szenarien bis Authentication Assurance Level 2 geeignet sein. Für AAL3 verlangt NIST dagegen nicht exportierbare Schlüssel in einer hardwaregeschützten Umgebung oder einem separaten Authentikator. Das bedeutet nicht, dass synchronisierte Passkeys schwach sind. Es bedeutet, dass Komfort und Schlüsselportabilität ein anderes Assurance-Modell erzeugen.

Genau in diesem zusätzlichen Vertrauensbereich setzt Pass-ta-key an.

Der genaue Scope der Forschung

Unit 42 nennt mehrere Voraussetzungen, die in vielen Schlagzeilen zu kurz kamen:

• Google Password Manager verwaltet die betroffenen synchronisierten Passkeys.
• Chrome läuft auf Windows.
• Das Gerät besitzt ein TPM.
• Malware läuft bereits im Benutzerkontext des Opfers.
• Der Benutzer ist in der relevanten Chrome- und Google-Umgebung eingerichtet.
• Für einzelne Varianten muss die Malware lokale Chrome-Daten lesen, Zustandsdateien manipulieren oder Chrome-Prozessspeicher untersuchen.

Nicht gezeigt wurde ein universeller Angriff gegen jeden Passkey. Ebenso wenig wurde gezeigt, dass ein entfernter Angreifer ohne vorherige Endpoint-Kompromittierung einfach einen WebAuthn-Schlüssel aus dem TPM zieht.

Die Formulierung „Passkeys wurden geknackt“ wäre deshalb falsch. Präzise ist: Unit 42 demonstrierte drei Angriffsketten gegen die Vertrauens-, Onboarding- und Recovery-Mechanismen synchronisierter Google-Passkeys auf kompromittierten Windows-Endpoints.

Phase null: Die lokale Passkey-Landkarte

Bevor eine der drei Varianten beginnt, liest die Malware laut Unit 42 die lokale Chrome-Sync-Datenbank aus. Dort liegen WebauthnCredentialSpecifics-Datensätze. Sie enthalten unter anderem Relying-Party-Informationen, Benutzernamen, Credential-IDs und verschlüsseltes privates Schlüsselmaterial.

Der von der Forschung genannte Pfad lautet:

%LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB

Der Zugriff auf diese Datensätze benötigte im Test keine erhöhten Rechte. Das private Schlüsselmaterial liegt zwar nicht direkt im Klartext vor, die Metadaten geben der Malware aber eine Zielliste: Für welche Dienste existieren Passkeys, zu welchen Konten gehören sie und welche Credential-ID muss angesprochen werden?

Das ist bereits aus Detection-Sicht relevant. Ein Infostealer muss seine Ziele nicht mehr erraten. Er kann zuerst inventarisieren und danach selektiv hochwertige Konten angreifen.

Pass-ta-key: Eine gültige Assertion ohne Benutzeraktion

Die erste Variante missbraucht den Geräteschlüssel, mit dem Chrome gegenüber dem Google Cloud Authenticator die Identität des Windows-Geräts nachweist.

Chrome erzeugt hierfür einen TPM-gestützten Identity Key. Unit 42 beschreibt, dass Chrome den privaten Schlüssel nicht als gewöhnlichen Klartextschlüssel speichert. Stattdessen exportiert Chrome ihn über Windows CNG als NCRYPT_OPAQUE_KEY_BLOB. Das TPM schützt diesen Blob so, dass er auf demselben physischen TPM wieder für kryptografische Operationen importiert werden kann.

Das ist kryptografisch sinnvoll, löst aber nicht automatisch das Autorisierungsproblem. Laut Forschung konnte Malware im normalen Benutzerkontext den gespeicherten wrapped_identity_private_key lesen oder aus dem Chrome-Speicher gewinnen und die regulären Windows-CNG-Funktionen aufrufen. Das TPM führt dann eine Signatur aus, weil die Anfrage technisch vom richtigen Gerät kommt. Es weiss nicht, ob Chrome oder Malware die API aufgerufen hat.

Der Ablauf sieht vereinfacht so aus:

Angreifer fordert beim Onlinedienst eine frische Challenge an
    -> Malware auf dem Opfer-PC nutzt den TPM-gebundenen Identity Key
    -> Google Cloud Authenticator akzeptiert die Geräteidentität
    -> Cloud Authenticator erzeugt eine gültige Passkey-Assertion
    -> Angreifer reicht die Assertion beim Onlinedienst ein

Die private Passkey-Datei wird in dieser Variante nicht zwingend exportiert. Die Malware nutzt das kompromittierte Gerät und Googles Cloud Authenticator als Signaturdienst.

Die natürliche Grenze ist das UV-Flag. Der Identity Key bestätigt Gerätebesitz, aber keine erfolgreiche PIN- oder Biometrieprüfung. Ein korrekt implementierter Dienst, der User Verification zwingend verlangt und das Ergebnis prüft, muss die Assertion mit UV = 0 ablehnen.

Das macht die Variante nicht harmlos. Viele Dienste konfigurieren User Verification aus Kompatibilitäts- oder UX-Gründen nur als preferred. Andere fordern sie an, prüfen die Antwort aber fehlerhaft. In solchen Fällen wird aus dem als Multi-Faktor gedachten Login praktisch ein Faktor: Zugriff auf die Geräteidentität.

Silver Pass-ta-key: Der Angreifer registriert seine eigene UV-Identität

Silver Pass-ta-key umgeht die gerade beschriebene Grenze. Der Angreifer versucht nicht, Windows Hello oder die Biometrie des Opfers zu knacken. Er bringt den Cloud Authenticator dazu, einen eigenen Schlüssel künftig als gültigen Nachweis für User Verification zu akzeptieren.

Der Ausgangspunkt ist der Re-Onboarding-Prozess. Die Malware kann laut Forschung den bestehenden Gerätezustand beim Cloud Authenticator vergessen lassen oder lokal die Datei passkey_enclave_state löschen. Beim nächsten Passkey-Vorgang muss Chrome das Gerät neu registrieren.

Auf Windows wird der User-Verification-Key nicht zwingend beim ersten Schritt angelegt. Chrome kann zunächst den Google-Password-Manager-Recovery-PIN verwenden und den Zustand uv_key_pending setzen. Der eigentliche UV-Key folgt beim nächsten Passkey-Einsatz. Dieses auf Benutzerfreundlichkeit optimierte Zwischenstadium eröffnet das Zeitfenster.

Für die Vorbereitung muss das Opfer den unerwartet ausgelösten Recovery- beziehungsweise Re-Onboarding-Schritt durchlaufen und den GPM-PIN eingeben. Die Malware muss den PIN dabei nicht stehlen. Sie nutzt den danach entstandenen uv_key_pending-Zustand. Die späteren missbräuchlichen Logins können dann ohne weitere Interaktion und ohne erreichbares Opfergerät stattfinden.

Der Angreifer erzeugt in seiner eigenen Umgebung ein Schlüsselpaar und sendet den öffentlichen Schlüssel als neuen UV-Key. Nach den Ergebnissen von Unit 42 validierte der Google Cloud Authenticator bei diesem Vorgang nicht, ob der neue Schlüssel wirklich aus vertrauenswürdiger Hardware stammt. Das System speicherte den Angreiferschlüssel neben der legitimen Geräteidentität.

Ab diesem Punkt kann der Angreifer Anfragen selbst mit seinem privaten Schlüssel signieren. Der Cloud Authenticator behandelt sie wie eine lokal erfolgte Benutzerverifikation und erzeugt Assertions mit gesetztem UV-Flag. Der Opfer-PC muss bei späteren Logins nicht mehr online sein.

Der öffentlich einsehbare Chromium-Issue beschreibt dieses Verhalten als „GPM Passkeys Are Vulnerable to User Verification Key Abuse“. Zum Zeitpunkt meiner Prüfung war er als WAI markiert. Unabhängig von der internen Bewertung zeigt der Fall eine wichtige Architekturregel: Ein Recovery- oder Onboarding-Prozess, der neue vertrauenswürdige Schlüssel bindet, ist selbst ein hochkritischer Authentisierungsvorgang.

Golden Pass-ta-key: Aus Cloud-Sync wird exportierbares Schlüsselmaterial

Golden Pass-ta-key ist die schwerwiegendste Variante. Sie zielt auf das Security Domain Secret, kurz SDS. Dieses 32 Byte lange Geheimnis schützt die synchronisierten privaten Passkey-Schlüssel eines Google-Password-Manager-Kontos.

Das Architekturversprechen lautet vereinfacht: Der Client besitzt nur ein verschlüsseltes wrapped_secret. Die Entschlüsselung findet im Cloud Authenticator mit einem gerätespezifischen Schlüssel statt. Selbst Malware auf dem Client soll dadurch nicht einfach an die Passkey-Privatschlüssel gelangen.

Beim Onboarding und bei der Recovery muss die Sync-Infrastruktur jedoch Geräte wieder in die Security Domain aufnehmen. Unit 42 fand, dass Chrome dabei das SDS in einer für den Client zugänglichen Form erhält. Zunächst erschien es sogar im FIDO-Diagnoselog von Chrome. Google entfernte diese Logausgabe nach der Meldung. Das SDS gelangt während des Prozesses weiterhin in den Chrome-Prozessspeicher.

Auch Golden Pass-ta-key ist deshalb kein beliebiger Speicherabzug zu jedem Zeitpunkt. Die Malware erzwingt zunächst den sicherheitskritischen Onboarding- oder Recovery-Pfad und muss den Moment treffen, in dem das SDS im Chrome-Prozess vorhanden ist. Das macht den Angriff aufwendiger, ändert nach erfolgreicher Extraktion aber nicht die Reichweite des erbeuteten Geheimnisses.

Die Angriffskette kombiniert deshalb mehrere Schritte:

1. Die Malware erzwingt ein neues Onboarding.
2. Sie wartet auf die Neuerstellung oder Änderung des lokalen Enclave-Zustands.
3. Sie liest den Chrome-Prozessspeicher im passenden Moment aus und sucht nach dem SDS.
4. Sie verbindet das SDS mit den zuvor gelesenen Sync-Datensätzen.
5. Sie entschlüsselt die darin enthaltenen privaten Passkey-Schlüssel.
6. Ein eigener, vom Opfergerät unabhängiger Authentikator kann danach gültige Assertions erzeugen.

Hier liegt der qualitative Unterschied zu einem gestohlenen Session-Cookie. Eine Sitzung kann ablaufen oder serverseitig widerrufen werden. Golden Pass-ta-key soll dagegen die privaten Schlüssel aller bereits synchronisierten Passkeys exportieren. Unit 42 schreibt ausserdem, dass dasselbe SDS auch künftig erstellte synchronisierte Passkeys schützt und in der untersuchten Architektur keine sichtbare Möglichkeit zur Rotation oder zum Widerruf dieses SDS bestand.

Diese Aussage beschreibt den Stand der untersuchten Google-Implementierung. Sie ist kein Beweis dafür, dass jeder Passkey-Provider denselben Master-Key-Aufbau verwendet oder dass Google die Architektur nie mehr ändern kann.

Warum lokale Malware den Angriff nicht belanglos macht

Wer bereits beliebige Malware im Benutzerkontext eines angemeldeten PCs ausführen kann, besitzt zahlreiche einfachere Angriffsmöglichkeiten. Er kann Session-Cookies stehlen, Browserinhalte mitlesen, Transaktionen manipulieren, Dateien exfiltrieren oder den Benutzer direkt im aktiven Konto vertreten. Kein Authentisierungsverfahren kann einem vollständig kompromittierten Client uneingeschränkt vertrauen.

Auch die grundlegende Angriffsklasse ist nicht neu. Geheimnisse oder aktive Sessions aus einem kompromittierten Password Manager und Browser zu entwenden, gehört seit Jahren zum Werkzeugkasten von Infostealern. Pass-ta-key macht aus einer bereits bestehenden Endpoint-Kompromittierung keinen magischen Fernangriff.

Den Angriff deshalb als belanglos abzutun, greift trotzdem zu kurz. Die Forschung liefert konkrete, implementationsspezifische Erkenntnisse, die vorher nicht selbstverständlich waren:

• Ein unprivilegierter Prozess konnte einen TPM-gebundenen Chrome-Geräteschlüssel für Signaturen verwenden.
• Die Grenze zwischen Gerätebesitz und Benutzerverifikation hing bei Relying Parties an der korrekten Auswertung des UV-Flags.
• Der Re-Onboarding-Zustand erlaubte die Registrierung eines angreiferkontrollierten UV-Keys.
• Das zentrale Sync-Geheimnis erschien zunächst im Log und blieb danach laut Forschung im Prozessspeicher erreichbar.
• Der schwerste Pfad machte synchronisierte private Schlüssel ausserhalb des ursprünglichen Geräts wiederverwendbar.
• Für synchronisierte Passkeys fehlt häufig der klassische Signaturzähler als zuverlässiges Cloning-Signal, weil mehrere legitime Geräte denselben Credential verwenden.

„Endpoint kompromittiert“ ist eine Vorbedingung, aber keine vollständige Schadensbeschreibung. In der Incident Response macht es einen grossen Unterschied, ob ein Angreifer nur eine temporäre Session gestohlen hat oder ob er langfristig nutzbares privates Schlüsselmaterial für zahlreiche Dienste besitzt.

Pass-ta-key ist nur ein Teil der neuen Angriffsfläche

Pass-ta-key erschien nicht isoliert. Forschung aus den Jahren 2025 und 2026 zeigt mehrere Wege, auf denen Angreifer die Schutzwirkung eines Passkeys reduzieren können, ohne dessen privaten Schlüssel mathematisch zu brechen.

Beim Missbrauch von Sync und Recovery benötigt Pass-ta-key bereits laufende Malware auf dem Windows-Endpoint. Pass-the-Passkey kombiniert dagegen den Zugriff auf eine protokollierte Assertion mit einer serverseitigen Replay-Lücke. Beim FIDO-Downgrade reicht ein zusätzlich aktivierter, phishbarer Anmeldeweg, während Passkeys Pwned eine bösartige Browser-Erweiterung oder Script-Ausführung im Browserkontext voraussetzt. Infostealer greifen schliesslich nicht den Passkey selbst an, sondern stehlen die bereits authentisierte Sitzung aus einem kompromittierten Browser oder Endpoint.

Keiner dieser Wege bricht die Public-Key-Kryptografie. Gemeinsam ist ihnen, dass sie eine Vertrauensschicht rund um WebAuthn angreifen: Sync und Recovery, die serverseitige Prüfung, den Browser oder die Sitzung nach dem Login.

Diese Unterscheidung ist mehr als Wortklauberei. Ein Protokollbruch würde sämtliche konformen Implementierungen fundamental infrage stellen. Die hier beschriebenen Fälle verlangen dagegen unterschiedliche Gegenmassnahmen auf Endpoint-, Browser-, Identity- und Serverseite.

Pass-the-Passkey: Wenn eine gültige Assertion wiederverwendbar wird

SpecterOps identifizierte zur Black Hat USA 2026 drei Schwachstellen in Windows 11 und Microsoft Entra ID sowie mehr als 20 daraus abgeleitete Angriffstechniken. Die wichtigste Kette begann an einer unerwarteten Stelle: Windows protokollierte vollständige WebAuthn-Assertions im Event Log Microsoft-Windows-WebAuthN/Operational.

Eine solche Assertion enthält unter anderem Credential-ID, Challenge, Authenticator-Daten und Signatur. Sie ist kein privater Schlüssel und sollte bei korrekter Verifier-Implementierung nur einmal und nur in der zugehörigen Anmeldesitzung funktionieren. SpecterOps stellte jedoch fest, dass Entra ID aufgezeichnete Assertions innerhalb eines begrenzten Zeitfensters erneut akzeptierte. Damit trafen zwei Fehler aufeinander:

Windows protokolliert eine vollständige Assertion
    -> ein Angreifer liest sie aus
    -> der Verifier bindet Challenge und Assertion nicht ausreichend an die Sitzung
    -> dieselbe signierte Antwort wird erneut akzeptiert

Der Windows-Anteil erhielt die Kennung CVE-2026-34348. Microsoft veröffentlichte am 14. Juli 2026 ein Update, das die protokollierte Signatur auf wenige Bytes kürzt und damit die Replay-Quelle beseitigt. Zusätzlich wurde für bestimmte FIDO2-Security-Keys eine serverseitige Prüfung von Signaturzählern eingeführt. Signaturzähler sind aber kein universeller Schutz. Manche Plattform- und synchronisierten Credentials liefern konstant null oder teilen sich Zustände über mehrere Geräte.

Die technische Lehre reicht über diese inzwischen unterbrochene Exploit-Kette hinaus. WebAuthn-Assertions gehören nicht in Diagnose- oder Event-Logs. Challenges müssen zufällig, kurzlebig, einmalig und an die konkrete Anmeldesitzung gebunden sein. Eine gültige Signatur allein beweist nicht, dass der gesamte Login-Flow korrekt war.

Eine weitere Angriffstechnik betrifft das Parent-Window-Handle der Windows-WebAuthn-API. Ein lokaler Prozess kann einen echten Passkey-Dialog so anordnen, dass er optisch zu einem vertrauenswürdigen Programm wie Browser oder Mailclient zu gehören scheint. Auch hier ist die System-UI echt, aber der auslösende Kontext kann irreführend sein. Benutzer sollten deshalb unerwartete Passkey- und Windows-Hello-Abfragen genauso behandeln wie unerwartete MFA-Push-Nachrichten.

Der schwächste Fallback bestimmt die reale Sicherheitsstufe

Proofpoint demonstrierte 2025 einen FIDO-Downgrade gegen Microsoft Entra ID. Ein modifizierter Evilginx-Flow gab sich als Browser aus, der FIDO nicht unterstützt. Die Zielplattform bot daraufhin alternative Anmeldeverfahren an. Wählte das Opfer SMS, OTP oder eine andere phishbare Methode, konnten Zugangsdaten und Sitzung im Adversary-in-the-Middle-Flow abgegriffen werden.

Der Angriff umgeht nicht das Origin Binding. Er sorgt dafür, dass die WebAuthn-Zeremonie gar nicht erst beginnt. Das funktioniert nur, wenn für das Konto neben dem Passkey eine schwächere Methode zugelassen ist. Eine Ausnutzung in freier Wildbahn ist für diesen Downgrade nicht dokumentiert.

Für Unternehmen folgt daraus eine unbequeme, aber klare Regel: Eine Richtlinie ist nicht phishing-resistent, nur weil ein Passkey registriert wurde. Sie ist es erst dann, wenn die Anmeldung für den jeweiligen Schutzbedarf keine phishbaren Ausweichwege mehr akzeptiert. Recovery und Helpdesk-Reset müssen dabei in dieselbe Bewertung einbezogen werden.

Der Browser gehört zum Sicherheitsmodell

SquareX zeigte unter dem Namen Passkeys Pwned, wie eine bösartige Browser-Erweiterung oder Script-Ausführung im Browserkontext den Aufruf von navigator.credentials.create() und navigator.credentials.get() beeinflussen kann. Besonders relevant ist die Registrierung: Gelingt es einem Angreifer, im richtigen Moment eigenes Schlüsselmaterial einzuschleusen, kann der Benutzer einen echten biometrischen Dialog sehen, während im Hintergrund ein Credential unter Kontrolle des Angreifers gebunden wird.

Diese Forschung stammt von einem Security-Anbieter und sollte nicht mit einem universellen Browser-Exploit gleichgesetzt werden. Die notwendige Vorbedingung ist bereits erheblich: Die Erweiterung oder der Script-Kontext muss sich im WebAuthn-Pfad positionieren können. Trotzdem ist die Architekturlehre valide. Browser-Erweiterungen, Content Scripts und legitime WebAuthn-Proxy-Funktionen sind Teil der Trusted Computing Base. In verwalteten Umgebungen sind Extension-Allowlists und die Kontrolle privilegierter Browser-APIs deshalb Identity-Schutz, nicht nur Browser-Hygiene.

Passkeys schützen den Login, nicht automatisch die Sitzung danach

Nach einer erfolgreichen Anmeldung arbeitet der Webdienst gewöhnlich mit einem Session-Cookie oder Token weiter. Kann ein Infostealer dieses Sitzungsartefakt aus dem Browser entwenden und lässt der Server eine Wiederverwendung von einem anderen Gerät zu, muss der Angreifer weder Passwort noch Passkey besitzen. Er greift die bereits authentisierte Sitzung an.

Das ist heute der praktischere Angriffspfad als viele der beschriebenen Forschungs-Proofs-of-Concept. Passkeys verkleinern die Angriffsfläche vor und während des Logins erheblich. Sie ersetzen aber keine sichere Token-Speicherung, kurze und risikogerechte Sitzungsdauer, erneute Authentisierung für kritische Aktionen, Token-Widerruf und möglichst eine kryptografische Bindung hochwertiger Sitzungen an das verwendete Gerät.

Die Aussage „MFA wurde umgangen“ ist bei Session-Diebstahl deshalb oft irreführend. Die MFA wurde erfolgreich abgeschlossen. Gestohlen wurde das Resultat danach.

PoisonSeed zeigt, wie schnell aus Forschung Hype wird

Expel meldete im Juli 2025 zunächst einen vermeintlichen Angriff auf die Cross-Device-Authentisierung mit Passkeys. Ein Angreifer sollte einen legitimen QR-Code über eine Phishing-Seite an das Opfer weiterreichen und so den Login aus der Ferne übernehmen können. Wenige Tage später zog Expel die zentrale Behauptung öffentlich zurück und entschuldigte sich.

Die nachträgliche Analyse ergab, dass die für Cross-Device Authentication vorgesehene lokale Näheprüfung nicht erfolgreich überwunden worden war. Ohne die erforderliche Nähe lief der Vorgang aus, sämtliche MFA-Versuche scheiterten und der Angreifer erhielt keinen Zugriff.

Der Fall ist für die heutige Debatte besonders nützlich. Nicht jede plausibel klingende Kombination aus QR-Code, Phishing und Passkey ist ein funktionierender FIDO-Bypass. Gute Security-Kommunikation muss zwischen beobachteter Kontoübernahme, reproduziertem Proof of Concept, theoretischem Angriff und widerlegter Hypothese unterscheiden.

Meine Security-Bewertung

Die technische Reichweite von Pass-ta-key ist begrenzt. Nachgewiesen wurde die Angriffskette gegen Google Password Manager in Chrome auf Windows-Systemen mit TPM. Die Eintrittswahrscheinlichkeit liegt im mittleren bis niedrigen Bereich, weil bereits Malware lokal laufen und je nach Variante Zustände oder Prozessspeicher gezielt manipulieren muss.

Die mögliche Auswirkung ist dagegen hoch bis sehr hoch. Ein erfolgreicher Angriff kann zur Kontoübernahme, zu dauerhaftem Remote-Zugriff oder zur Extraktion mehrerer privater Schlüssel führen. Das Protokollrisiko bleibt niedrig, denn WebAuthn, Origin Binding und die Public-Key-Kryptografie werden nicht gebrochen.

Für einen normalen Benutzer bleibt ein synchronisierter Passkey in aller Regel sicherer als ein Passwort mit SMS-Code oder TOTP. Er entfernt Phishing, Credential Stuffing und den Diebstahl wiederverwendbarer Passwortdaten aus vielen realistischen Angriffspfaden.

Für privilegierte Administratoren, Finanzfreigaben, Produktionszugänge oder besonders regulierte Systeme genügt diese allgemeine Aussage nicht. Dort sollte die Organisation bewusst entscheiden, ob ein synchronisierter Passkey das gewünschte Assurance-Niveau erreicht. Ein gerätegebundener Plattformschlüssel oder ein separater FIDO2-Hardware-Key kann für solche Konten die passendere Grenze bilden.

Das ist keine Absage an Sync-Passkeys. Es ist eine abgestufte Sicherheitsarchitektur.

Was Betreiber von Webdiensten prüfen müssen

Die wichtigste Lehre für Relying Parties ist nicht exotisch. Sie ist saubere WebAuthn-Validierung.

Server sollten:

• userVerification: "required" setzen, wenn der Use Case echte lokale Benutzerverifikation verlangt,
• das zurückgesendete UV-Flag in authenticatorData zwingend prüfen,
• Challenge, Origin, Relying-Party-ID und Signatur vollständig validieren,
• jede Challenge zufällig erzeugen, kurz befristen, nur einmal akzeptieren und an die konkrete Sitzung binden,
• vollständige Assertions, Signaturen und andere wiederverwendbare Authentisierungsartefakte aus Logs fernhalten,
• Passkey-Registrierung, Entfernung und Account-Recovery als hochriskante Events protokollieren,
• neue Authentikatoren bei privilegierten Konten nur nach starker erneuter Authentisierung zulassen,
• nach Möglichkeit Herkunft und Eigenschaften des Authentikators erfassen,
• für Hochsicherheitsfälle Attestation und verwaltete Authentikatoren prüfen,
• ungewöhnliche Gerätewechsel, Geo-Wechsel und neue Passkey-Bindungen in die Identity-Telemetrie aufnehmen,
• Sitzungen nach risikoreichen Änderungen widerrufen und kritische Aktionen erneut authentisieren,
• gerätegebundene Sessions einsetzen, sobald Plattform und Anwendung dies belastbar unterstützen.

Eine etablierte WebAuthn-Bibliothek reduziert das Risiko unvollständiger Eigenimplementierungen, entbindet den Betreiber aber nicht von der Prüfung ihrer Konfiguration. Der eBay-Fall zeigt, wie ein einzelnes nicht ausgewertetes Flag die beabsichtigte Sicherheitsstufe reduzieren kann. Pass-the-Passkey zeigt zusätzlich, dass selbst eine korrekte Signatur wertlos wird, wenn Challenge und Sitzung nicht korrekt zusammengehören.

Was Unternehmen bei Passkey-Rollouts ändern sollten

Passkey-Projekte werden oft als IAM-Projekt geplant. Pass-ta-key zeigt, dass sie gleichzeitig Endpoint-, Browser- und Recovery-Projekte sind.

Für normale Workforce-Konten können synchronisierte Passkeys weiterhin sinnvoll sein. Sie reduzieren Helpdesk-Aufwand und schützen Benutzer sehr wirksam gegen Phishing. Für privilegierte Rollen sollte die Richtlinie aber klar nach dem Schutzbedarf unterscheiden.

Normale Benutzerkonten können synchronisierte Passkeys auf verwalteten Geräten verwenden, kombiniert mit Endpoint-Schutz und Conditional Access. Für sensitive Fachkonten sind verwaltete Plattform-Authentikatoren oder eingeschränkte Sync-Umgebungen mit stärkerer Gerätebindung angemessen. Admin-, Break-Glass- und andere Hochwertkonten sollten separate gerätegebundene FIDO2-Hardware-Keys, streng kontrollierte Recovery und keine unkontrollierte Cloud-Synchronisierung verwenden.

Zusätzlich sollten Unternehmen:

• Chrome und Windows aktuell halten,
• den Windows-Sicherheitsstand gegen CVE-2026-34348 kontrollieren,
• Passkey-Speicherung im eingebauten Browser-Manager über Enterprise Policies bewusst erlauben oder begrenzen,
• Browser-Erweiterungen per Allowlist steuern und privilegierte WebAuthn-Proxy-Funktionen überwachen,
• EDR und Application Control auch auf Benutzerprozesse ausrichten,
• Zugriffe auf Browser-Sync-Datenbanken und Dumps von Chrome-Prozessspeicher überwachen,
• Löschung oder unerwartete Neuerstellung von passkey_enclave_state untersuchen,
• wiederholte oder unerwartete Google-Password-Manager-Recovery-PIN-Abfragen als Warnsignal behandeln,
• bestehende Prozesse für Geräteverlust und Account-Recovery gegen Missbrauch testen,
• phishbare Fallbacks für privilegierte Konten entfernen oder durch eine Authentication-Strength-Policy ausschliessen,
• unerwartete Passkey-Prompts, neue Credential-Registrierungen und WebAuthn-Nutzung aus ungewöhnlichen Prozessen untersuchen,
• inventarisieren, welche wichtigen Dienste synchronisierte und welche gerätegebundene Credentials verwenden.

Der entscheidende organisatorische Punkt lautet: Endpoint Detection ist kein vom Passkey-Projekt unabhängiger Budgetposten. Wenn der Authentikator im Browser und auf dem Client lebt, gehört Endpoint-Sicherheit direkt zum Authentisierungsmodell.

Was Benutzer jetzt tun sollten

Es gibt keinen sachlichen Grund, vorsorglich alle Passkeys zu löschen und wieder schwächere Passwörter zu verwenden.

Sinnvoll ist:

• Chrome und Windows zeitnah aktualisieren,
• nur vertrauenswürdige Software und Browser-Erweiterungen installieren,
• den Geräteschutz, Windows Hello und Malware-Schutz aktiv halten,
• unerwartete Passkey- oder Windows-Hello-Dialoge nicht bestätigen,
• unerwartete Recovery-PIN- oder Re-Onboarding-Abfragen nicht beiläufig bestätigen,
• in Google Password Manager und bei wichtigen Diensten registrierte Geräte und Passkeys kontrollieren,
• für besonders wertvolle Konten einen separaten Hardware Security Key erwägen,
• einen verdächtigen Endpoint nicht einfach weiterverwenden, sondern isolieren und untersuchen lassen.

Wer konkrete Hinweise auf Malware, manipulierte Chrome-Zustände oder einen Speicherabzug hat, sollte von einem möglichen Credential- und Session-Diebstahl ausgehen. Dann reicht ein Passwortwechsel nicht. Notwendig sind Endpoint-Neuaufbau oder belastbare Bereinigung, Widerruf aktiver Sitzungen, Kontrolle der Recovery-Methoden, Entfernung unbekannter Passkeys und erneute Registrierung vertrauenswürdiger Authentikatoren.

Bei einem möglichen Golden-Pass-ta-key-Vorfall ist besondere Vorsicht nötig. Der veröffentlichte Forschungsstand beschreibt keine einfache SDS-Rotation für Benutzer. Das bedeutet: Nicht behaupten, ein PIN-Wechsel oder das blosse Neuerstellen eines einzelnen Passkeys löse das Problem garantiert. Für wertvolle Konten würde ich nach der Endpoint-Bereinigung neue gerätegebundene Credentials registrieren, alte synchronisierte Credentials entfernen und den Provider beziehungsweise das Incident-Response-Team in die Wiederherstellung einbeziehen.

Die eigentliche Lehre

Passkeys sind kein Schutzschild gegen jede Form von Kompromittierung. Sie lösen ein konkretes, sehr grosses Problem: Menschen müssen kein wiederverwendbares Geheimnis mehr an einen Server oder eine möglicherweise gefälschte Website übergeben.

Pass-ta-key zeigt die nächste Ebene. Sobald private Schlüssel bequem zwischen Geräten synchronisiert werden, entsteht eine Infrastruktur für Schlüsselverschlüsselung, Gerätevertrauen und Recovery. Diese Infrastruktur kann Fehler enthalten, auch wenn das zugrunde liegende WebAuthn-Protokoll korrekt ist.

Die falsche Reaktion wäre, Passkeys als gescheitert zu erklären. Die ebenso falsche Reaktion wäre, jeden Angriff nach einer lokalen Malware-Infektion als banal abzutun.

Meine Einschätzung bleibt deshalb klar: Passkeys weiter ausrollen, aber die Sicherheitsversprechen präzise formulieren. Synchronisierte Passkeys sind hervorragend gegen Phishing. Gerätegebundene Hardware-Keys bieten für Hochwertkonten eine stärkere Grenze. Und kein Authentikator ersetzt einen sauberen Endpoint, kontrollierte Recovery-Prozesse und korrekt implementierte serverseitige Prüfungen.

Passkeys haben die Tür gegen Phishing deutlich besser verriegelt. Pass-ta-key erinnert uns daran, dass ein Angreifer, der bereits im Haus steht, eine andere Verteidigung braucht.

Bis zum nächsten Mal,
Euer Joe

FAQ