Passkey-Angriffe über Google Password Manager: Risiken

Passkeys sollen das Anmelden deutlich sicherer machen, weil Nutzer nicht mehr ständig Codes, Passwörter oder klassische zweite Faktoren benötigen. Eine aktuelle Sicherheitsanalyse zeigt jedoch, dass Passkey-Angriffe in bestimmten Szenarien trotzdem möglich sein können – selbst wenn auf der Nutzerseite kein Fingerabdruck, keine PIN und keine sichtbare Bestätigung erscheint.

Wichtig vorweg: Die beschriebenen Wege beginnen nicht mit einer externen Zauberlösung. Die Angreifer brauchen bereits Malware auf dem betroffenen Windows-System. Von dort aus zielen die Techniken auf die Bereiche rund um die Passkey-Verarbeitung in Chrome ab – nicht auf die eigentliche Kryptografie.

Was die Forschung angreift

Die Untersucher von Unit 42 haben drei Angriffspfade beschrieben, die sich auf den cloudbasierten Authenticator im Google Password Manager in Chrome beziehen. In der Analyse werden die Pfade als Pass-ta-key, Silver Pass-ta-key und Golden Pass-ta-key bezeichnet. Alle drei Methoden richten sich darauf, dass eine einmal erlangte Position auf einem Gerät weiter ausgenutzt werden kann.

Die Kernaussage lautet: Die Angriffe brechen nicht die zugrunde liegende Kryptografie. Stattdessen gehen sie gegen das „Umfeld“ der Passkeys vor – also gegen, wie Chrome gerätespezifische Schlüssel verwaltet, wie eine erneute Registrierung (Re-enrollment) abläuft und wie ein Zielsystem die Nutzerprüfung bewertet.

Warum die Nutzer auf dem Bildschirm nichts sehen

Ein besonders beunruhigender Punkt der Passkey-Angriffe ist die mögliche Tarnung. Malware, die als normaler Prozess auf dem System läuft, soll sich gegenüber dem Passkey-Mechanismus so verhalten können, dass ein Konto bei einem Opfer übernommen werden kann, ohne dass eine übliche Nutzerverifikation sichtbar wird.

Nach Darstellung der Forscher können Angreifer dabei unter anderem eine gültige Authentifizierungszusage (Assertion) erzeugen, einen angriffsgesteuerten Schlüssel für die Nutzerverifikation einsetzen oder ein geheimes Material aus dem Prozesskontext auslesen. Ob und wie das im echten Alltag auftritt, wird in der Veröffentlichung nicht mit konkreten „in the wild“-Angriffen belegt.

Wichtig: „Post-Compromise“-Techniken, kein Erstzugriff

Die Grenzen der Forschung sind ebenfalls klar benannt. Die Techniken sind auf Chrome unter Windows beschränkt und setzen ein Gerät mit Trusted Platform Module (TPM) voraus. Zudem beginnen alle Pfade mit einer bereits laufenden Malware auf der betroffenen Maschine.

Außerdem handelt es sich um „Post-Compromise“-Methoden: Sie zeigen, was Angreifer erreichen können, wenn ein System bereits kompromittiert ist. Sie erklären nicht, wie die Kompromittierung selbst passiert.

Erster Pfad: Pass-ta-key und das fehlende UV-Flag

Der erste Angriffspfad, Pass-ta-key, setzt an der Speicherung und Handhabung der Geräteidentitätsschlüssel an. Malware kann dabei Chrome anweisen, einen durch die TPM-Logik signierten, angreiferstellten Request zu erledigen. Dazu werden Signaturaufrufe über die Windows Cryptography API genutzt.

Aus der Analyse geht hervor, dass die Schlüssel als „wrapped“ Identitätsschlüssel vorliegen können und dass der Zugriff später wiederverwendbar sein kann. Ein entscheidender Punkt ist dabei, dass die resultierende Authentifizierung im Vergleich zu einer echten Nutzerprüfung nur an einem Bit unterscheidbar ist: dem User Verified (UV)-Flag.

Wenn ein Relying Party (also der Dienst, bei dem man sich anmeldet) in der WebAuthn-Validierung userVerification auf „required“ setzt, sollte die Zeremonie eigentlich fehlschlagen, falls das UV-Bit nicht gesetzt ist. Die Forscher argumentieren jedoch, dass nicht alle Dienste diese Prüfung korrekt umsetzen.

In der Veröffentlichung wird genannt, dass ein Anbieter die UV-Prüfung (GitHub) korrekt durchsetzt, während bei einem anderen Anbieter (eBay) zunächst eine Lücke bestand, die nach der Offenlegung geschlossen wurde. Dadurch wird klar: Bei Passkey-Angriffen kann die Schwachstelle auch in der Server-Validierung und nicht nur im Browser liegen.

Zweiter Pfad: Silver Pass-ta-key durch erneute Registrierung

Beim zweiten Weg, Silver Pass-ta-key, verschiebt sich der Fokus. Der Pfad zielt darauf, dass Chrome eine erneute Gerätere-Registrierung (Re-enrollment) durchführt. Dabei, so die Beschreibung, wird die Nutzerverifikations-Schlüsselkomponente nicht sofort erzeugt. In dieser zeitlichen Lücke soll ein Angreifer einen eigenen Schlüssel registrieren können.

Die Konsequenz: Signaturen mit diesem „neuen“ Schlüssel tragen das UV-Flag. Laut Unit 42 kann das später ermöglichen, dass der Angreifer ohne das betroffene Opfergerät weitere Logins durchführen kann.

Die Veröffentlichung macht außerdem deutlich, dass es unklar ist, ob und wie ein konkreter Produktionsdienst mittlerweile gegen diese Art von Schlüsselersetzung mit Hardwarenachweisen (Attestation) absichert. Die Forscher empfehlen für die Eindämmung genau solche Prüfungen – also dass ersetzte Schlüssel nur akzeptiert werden, wenn sie aus sicherer Hardware stammen.

Dritter Pfad: Golden Pass-ta-key und das Security Domain Secret

Der dritte Angriffspfad, Golden Pass-ta-key, geht noch direkter an das geheime Material. Hier soll Malware Re-enrollment auslösen, anschließend ein Geheimnis – das Security Domain Secret (SDS) mit einer Länge von 32 Byte – aus dem Speicher von Chrome auslesen, während es kurzzeitig unverschlüsselt im Prozesskontext vorliegt.

Mit dem SDS sollen Angreifer synchronisierte Passkey-private Schlüssel wiederherstellen können. Die Analyse nennt, dass Chromium-Quellen Teile der Architektur stützen: Chrome erstellt oder empfängt SDS als 32-Byte-Struktur in Client-Datenstrukturen. Damit ist zumindest plausibel, dass das Geheimnis tatsächlich in Chrome-Memory gelangt.

Offen bleibt aber, ob alle beschriebenen Teilziele zuverlässig erreicht werden können, inklusive Account Takeover und Persistenz über mehrere „Secret-Epochs“ hinweg. Diese Punkte werden in der Veröffentlichung entweder als ausstehend beschrieben oder dem Unit-42-Bericht zugeschrieben.

Was über Updates und konkrete Gegenmaßnahmen bekannt ist

In der Veröffentlichung steht, dass Google eine frühere SDS-Axposure aus FIDO-Logs entfernt habe und dass eBay inzwischen die UV-Validierung überprüfe. Gleichzeitig heißt es: Die Änderung am Logging schließt den beschriebenen Pfad nicht zwingend, weil das Geheimnis weiterhin beim Client in den Speicher gelangen soll.

Auch eine Prüfung in der National Vulnerability Database am 3. August 2026 ergab keine passenden CVE-Einträge für die drei benannten Angriffstechniken. Die Autoren nennen zudem keine konkreten betroffenen Chrome-Versionen und kein vollständiges Remediation-Statusbild.

Für Nutzer ist damit vor allem wichtig: Es gibt nach Angaben der Veröffentlichung keine dokumentierte SDS-spezifische Rotation oder Revocation-Kontrolle. Google-Support beschreibt zwar Möglichkeiten wie das Ändern eines Google Password Manager Pins oder das Löschen der Password-Manager-Daten, aber es wird nicht erklärt, ob das ein gestohlenes SDS tatsächlich unbrauchbar macht.

Empfohlene Sicherheitsprinzipien aus Sicht der Dienstanbieter

Die Analyse formuliert konkrete Leitlinien für Relying Parties und Credential Provider:

• Relying Parties sollen userVerification auf „required“ setzen und das zurückgelieferte UV-Bit prüfen, statt sich allein auf die Request-Einstellung zu verlassen.
• Credential Provider sollen neu registrierte Schlüssel per Hardware-Nachweisen attestieren und robustere Kontrollen für Registrierung sowie Wiederherstellung einführen.
• Außerdem wird empfohlen, den Zugriff auf lokale Passkey-Zustände einzuschränken und sicherzustellen, dass Master Keys nicht in Logs oder in einem für Angriffe nutzbaren Speicherbereich landen.

Was das für Nutzer bedeutet

Für betroffene Nutzer ist die Lage zweigeteilt. Einerseits ist die Schwelle hoch, weil die Passkey-Angriffe ein bereits kompromittiertes Gerät voraussetzen. Andererseits sind die beschriebenen Folgen ernst: Ein Angreifer könnte möglicherweise auch ohne sichtbare Prüfung Zugriff auf Passkey-geschützte Konten erlangen.

Die Veröffentlichung klärt nicht abschließend, ob ein Pin-Reset oder das Löschen der Password-Manager-Daten allein ein gestohlenes Geheimnis entkräftet. Wer einen Verdacht auf Kompromittierung hat, sollte daher nicht nur an einem einzelnen Schritt festhalten, sondern das gesamte Sicherheitsniveau erhöhen: verdächtige Prozesse entfernen, Systeme bereinigen und Konten- und Session-Schutz konsequent aktualisieren.

Fazit: Passkey-Angriffe zeigen die Grenzen isolierter Annahmen

Die beschriebenen Passkey-Angriffe verdeutlichen, dass Sicherheit nicht nur aus guter Kryptografie besteht. Auch die Implementierungsdetails rund um Schlüssel, Geräte-Neuregistrierung und die serverseitige Validierung der Nutzerprüfung sind entscheidend.

Solange Angreifer bereits Zugriff auf ein Endgerät haben, können „Post-Compromise“-Techniken die Schutzwirkung von Passkeys in bestimmten Konstellationen untergraben. Deshalb sollten sowohl Browser- und Cloud-Komponenten als auch Diensteingangs-Validierungen konsequent gegen fehlerhafte oder manipulierte UV-Informationen abgesichert werden.

Quelle: https://thehackernews.com/2026/08/google-password-manager-attacks-could.html