Affiliate-Offenlegung – dieser Artikel enthält einen Affiliate-Link zu einem Passwortmanager. Wenn Sie darüber ein Abo abschließen, erhalten wir eine Provision, ohne Mehrkosten für Sie. Am Folgenden ändert das nichts: Die Erkenntnisse unten stammen von Palo Alto Networks Unit 42 und der Fachpresse und sind Quelle für Quelle belegt.
Kurze Antwort: Ja, Passkeys sind weiterhin sicher im Einsatz – und die Forscher, die den Angriff veröffentlicht haben, sagen genau das. Am 3. August 2026 hat Palo Alto Networks Unit 42 gezeigt, dass Schadsoftware, die auf einem Windows-PC bereits läuft, über Google Password Manager synchronisierte Passkeys übernehmen kann. Ihr eigener Satz ist der, den man sich merken sollte: „These attacks do not break the underlying cryptography." („Diese Angriffe brechen die zugrunde liegende Kryptografie nicht.") Gebrochen haben sie das Drumherum des Passkeys, nicht den Passkey.
Genau diese Unterscheidung ist die ganze Geschichte, und die meisten Schlagzeilen haben sie weggelassen.
Was tatsächlich veröffentlicht wurde
Arie Olshtein, Forscher bei Unit 42, hat am 3. August 2026 „Pass the Passkey: A Novel Attack Surface in Passwordless Authentication" veröffentlicht. Es handelt sich um einen technischen Forschungsblogbeitrag, nicht um eine begutachtete Studie, und er stammt von einem kommerziellen Sicherheitsanbieter – das gehört klar gesagt, denn er ist detailliert und glaubwürdig, aber er kommt nicht von einer neutralen dritten Partei.
Beschrieben werden drei Techniken, zusammengefasst als die Pass-ta-key-Angriffe.
Pass-ta-key – die Schadsoftware zieht den verpackten privaten Device-Identity-Key von der Festplatte oder aus dem Speicher und ruft dann Windows-CNG-APIs auf (NCryptOpenStorageProvider, NCryptImportKey, NCryptSignHash), damit das TPM in ihrem Auftrag signiert. Sie signiert den Hash des WebSocket-Handshakes und gibt sich gegenüber Googles Cloud-Authenticator als legitime Chrome-Installation aus. Kein Entsperren des Geräts, keine Nutzerinteraktion, keine Rechteausweitung. Man beachte die Feinheit: Der Schlüssel verlässt das TPM nie – das TPM wird schlicht dazu gebracht, für den Angreifer zu arbeiten.
Silver Pass-ta-key – die Schadsoftware löscht passkey_enclave_state, um eine erneute Geräteregistrierung zu erzwingen, nutzt den flüchtigen Zustand uv_key_pending aus und registriert ihren eigenen User-Verification-Key. Der Fehler ist präzise: Der Cloud-Authenticator überprüft die Attestierung neu registrierter UV-Keys nicht, kann also nicht erkennen, ob sie aus sicherer Hardware stammen. Ergebnis: wiederverwendbarer Zugriff von einem anderen Rechner aus, ohne das Gerät des Opfers.
Golden Pass-ta-key – der schlimmste der drei. Das Security Domain Secret, ein 32 Byte großer Hauptschlüssel, der jeden synchronisierten Passkey schützt, wird während der erneuten Registrierung aus dem Prozessspeicher von Chrome extrahiert. Damit entschlüsselt ein Angreifer die gespeicherten Credential-Datensätze und nimmt jeden synchronisierten Passkey des Kontos mit.
Die zwei Tatsachen, die die Sache ernst machen
Google hat das Security Domain Secret nach der Offenlegung aus den Diagnoseprotokollen von Chrome entfernt. Unit 42 stellt jedoch fest, dass das Geheimnis weiterhin an den Client gesendet wird und im Prozessspeicher von Chrome zugänglich bleibt – eingeräumt, nicht behoben.
Und es gibt in der aktuellen Implementierung keine Möglichkeit, diesen Hauptschlüssel zu rotieren oder zu widerrufen. Gegenwärtige und künftige Passkeys bleiben durch dasselbe Geheimnis geschützt. Das ist der härteste Teil dieser Angelegenheit und der Teil, für den es keinen Behelf auf Nutzerseite gibt.
Die eine Bedingung, die alles verändert
Jede dieser Techniken setzt bereits auf dem Rechner laufende Schadsoftware voraus. Die Forscher sagen es: „malware already existing on the victim's device during the initial stage." („Schadsoftware, die während der Anfangsphase bereits auf dem Gerät des Opfers vorhanden ist.")
Frank Dickson von IDC hat es in Computerworld am klarsten formuliert: „This isn't passkeys getting hacked from across the internet. It's what [an attacker] does once they're already inside the house." („Hier werden nicht Passkeys quer durch das Internet gehackt. Es geht darum, was [ein Angreifer] tut, sobald er bereits im Haus ist.")
Der Wirkungsbereich ist also eng und genau umrissen:
| Bedingung | Erforderlich |
|---|---|
| Betriebssystem | Windows |
| Browser | Chrome |
| Anmeldedaten-Speicher | Google Password Manager (synchronisierte Passkeys) |
| Hardware | Rechner mit TPM |
| Voraussetzung | Bereits lokal laufende Schadsoftware |
| Benötigte Rechte | Nutzerebene – keine Ausweitung |
| Nutzerinteraktion | Keine |
Es braucht kein Phishing, keine bösartige Erweiterung, keine gestohlene Sitzung, keinen Rückfall auf einen anderen Faktor. Und keine Ausnutzung aus der Ferne: Wenn Ihr Rechner sauber ist, erreicht Sie nichts davon.
Apples iCloud Keychain, Windows Hello, 1Password und Bitwarden wurden nicht getestet. Unit 42 merkt an, dass andere Anbieter eine ähnliche Cloud-Authenticator-Bauweise verwenden – das ist eine Warnung zur Architektur, kein Nachweis, dass sie verwundbar sind. Wer Ihnen erzählt, „alle Passkeys sind betroffen", geht über die Forschung hinaus.
Was sich zu ändern lohnt
Wenn Sie Privatperson sind. Das einzige echte Schloss ist hier die eine Voraussetzung: Halten Sie Schadsoftware vom Rechner fern. Unit 42 empfiehlt selbst, in Endpoint-Schutz zu investieren und Passkeys als eine Schicht in einer breiteren Strategie zu behandeln statt als Ziellinie. Für Ihre wertvollsten Konten – E-Mail, Bank, Domain-Registrar – ist ein Hardware-Sicherheitsschlüssel die gerätegebundene Option, die diese Forschung nicht berührt, da nichts in eine Cloud-Enklave synchronisiert wird. Das ist ein Kompromiss, kein Urteil: Sie gewinnen Widerstandsfähigkeit gegen diese Angriffsklasse und verlieren den Komfort der Synchronisierung über mehrere Geräte hinweg.
Wenn Sie einen Dienst betreiben. Die konkrete Behebung liegt auf der Serverseite und ist benannt: userVerification verlangen und das UV-Flag in der Authentifizierungsantwort tatsächlich prüfen. Das ist nicht hypothetisch – eBay akzeptierte Authentifizierungen ohne Benutzerverifizierung, obwohl userVerification auf required gesetzt war, und hat das nach dem Bericht von Unit 42 korrigiert. GitHub hat denselben Angriff korrekt abgewiesen. Eine solide Implementierung hält stand, eine ungleichmäßige nicht. Wie der Analyst Justin Greis es in Computerworld zusammenfasste: „The specification is sound, but the ecosystem implementing it is uneven." („Die Spezifikation ist solide, aber das Ökosystem, das sie umsetzt, ist ungleichmäßig.")
Darüber hinaus die Maßnahmen, die von den Forschern und den in Computerworld zitierten Analysten dokumentiert werden: die Attestierung des Device-Keys bei der Registrierung prüfen, ungewöhnliche Passkey-Nutzung überwachen, EDR und Identity Threat Detection (ITDR) ausrollen, eine ausdrückliche Richtlinie zu synchronisierten gegenüber gerätegebundenen Anmeldedaten festlegen und die Wiederherstellungsabläufe proben – denn Wiederherstellung und erneute Registrierung sind genau das, was diese Angriffe missbrauchen.
Was man nicht schlussfolgern sollte
Mehrere Behauptungen, die in dieser Woche kursieren, werden von der Forschung nicht gestützt, und sie zu wiederholen wäre falsch:
- „Passkeys sind tot / gebrochen." Schriftlich widerlegt von Unit 42 und SecurityWeek.
- „Die Kryptografie wurde geknackt." Wurde sie ausdrücklich nicht.
- „Zurück zu Passwörtern." Keine Quelle empfiehlt das, und es würde Phishing und Passwort-Wiederverwendung wieder einführen – genau die Angriffe, die Passkeys beseitigen.
- „Es ist eine CVE, die aktiv ausgenutzt wird." Mit Stand 3. August war keine CVE vergeben, und es wurde keine Ausnutzung in freier Wildbahn gemeldet.
- „Apple und Microsoft sind ebenfalls betroffen." Ungetestet. Das ist nicht dasselbe.
Die ehrliche Zusammenfassung gehört Unit 42 selbst: Passkeys sind „a meaningful step forward in authentication security" („ein bedeutsamer Fortschritt für die Sicherheit der Authentifizierung"), weil sie geteilte Geheimnisse und damit ganze Angriffsklassen beseitigen. Diese Forschung kehrt das nicht um. Sie zeigt, dass das rund um Passkeys gebaute Ökosystem – Registrierung, Wiederherstellung, Cloud-Synchronisierung – dieselbe Prüfung verdient, die der Kryptografie bereits zuteilwurde.
Die tiefere Lehre, aufgeworfen von J. Wolfgang Goerlich in Computerworld, ist die, die man behalten sollte: Synchronisierte Passkeys haben ein Risiko der Übertragbarkeit von Anmeldedaten wieder eingeführt, das gerätegebundene Authenticator nie hatten. Komfort über mehrere Geräte hinweg hat seinen Preis, und zum ersten Mal können wir ihn deutlich sehen.
Quellen
- Arie Olshtein, „Pass the Passkey: A Novel Attack Surface in Passwordless Authentication", Palo Alto Networks Unit 42, 3. August 2026 – Primärquelle, kommerzieller Sicherheitsanbieter.
- BleepingComputer, 3. August 2026 – erste Berichterstattung, hält fest, dass keine CVE vergeben wurde.
- The Hacker News, 3. August 2026 – „the attacks go after the code around the passkey" („die Angriffe zielen auf den Code rund um den Passkey").
- SecurityWeek, 5. August 2026 – „That does not mean passkeys are broken" („Das bedeutet nicht, dass Passkeys gebrochen sind").
- Computerworld, Evan Schuman, 5. August 2026 – Analystenkommentare (Dickson, Greis, Goerlich, Levine, Finkelstein).
- Biometric Update, 7. August 2026 – die geltende Position der FIDO Alliance, keine Ausnutzung in freier Wildbahn.
Zahlen und Aussagen am 9. August 2026 überprüft. Google hatte sich zu diesem Zeitpunkt inhaltlich nicht öffentlich geäußert; das ist der Punkt, der sich seither am ehesten geändert haben dürfte.
★ Audit Cure53 2024 · ✓ Plan gratuit · Cross-platform
Ein Manager mit integrierter 2FA & Passkeys → NordPassTOTP & Passkeys speichern · XChaCha20 · Gratis-Tarif→Häufig gestellte Fragen
Sind Passkeys nach der Pass-ta-key-Forschung weiterhin sicher?
Ja, und die Forscher sagen es selbst. Palo Alto Networks Unit 42 stellt unmissverständlich fest, dass diese Angriffe die zugrunde liegende Kryptografie nicht brechen. SecurityWeek ergänzt, dass das nicht bedeutet, Passkeys seien gebrochen oder man solle aufhören, sie zu verwenden. Was die Forschung zeigt, ist, dass Schadsoftware, die bereits auf einem Windows-PC läuft, die Maschinerie rund um den Passkey missbrauchen kann – Googles Cloud-Synchronisierung – und nicht den Passkey selbst. Passkeys bleiben eine echte Verbesserung gegenüber Passwörtern, weil sie das geteilte Geheimnis beseitigen, auf das Phishing und Credential Stuffing angewiesen sind.
Was genau nutzen die Pass-ta-key-Angriffe aus?
Drei getrennte Techniken, alle am 3. August 2026 von Unit 42 veröffentlicht. Pass-ta-key extrahiert den verpackten Device-Identity-Key und nutzt die Windows-CNG-APIs, um das TPM im Auftrag des Angreifers signieren zu lassen und sich gegenüber Googles Cloud-Authenticator als legitime Chrome-Installation auszugeben. Silver Pass-ta-key erzwingt eine erneute Geräteregistrierung und registriert den eigenen User-Verification-Key des Angreifers, weil der Cloud-Authenticator die Attestierung neu registrierter UV-Keys nicht überprüft. Golden Pass-ta-key extrahiert das Security Domain Secret, einen 32 Byte großen Hauptschlüssel, aus dem Prozessspeicher von Chrome – damit lässt sich jeder synchronisierte Passkey des Kontos entschlüsseln.
Bin ich betroffen?
Nur unter ganz bestimmten Bedingungen, und sie müssen alle gleichzeitig zutreffen: Windows, Chrome, über Google Password Manager synchronisierte Passkeys, ein Rechner mit TPM und vor allem Schadsoftware, die bereits auf diesem Rechner läuft. Eine Ausnutzung aus der Ferne gibt es nicht: Die Forscher stellen fest, dass der Angriff bereits auf dem Gerät des Opfers vorhandene Schadsoftware voraussetzt. IDC-Analyst Frank Dickson hat es in Computerworld klar formuliert – hier werden nicht Passkeys quer durch das Internet gehackt, sondern es geht darum, was ein Angreifer tut, wenn er bereits im Haus ist.
Sind Apple, Microsoft oder Passwortmanager von Drittanbietern betroffen?
Nicht belegt, und es wäre falsch, etwas anderes zu behaupten. Unit 42 hat Google Password Manager in Chrome unter Windows getestet. iCloud Keychain, Windows Hello, 1Password, Bitwarden und andere wurden nicht getestet. Unit 42 weist allerdings darauf hin, dass andere Anbieter ein ähnliches Cloud-Authenticator-Modell verwenden – das ist eine Warnung zur Bauweise, kein Nachweis einer Schwachstelle. Behandeln Sie sie als ungetestet, weder als sicher noch als verwundbar.
Hat Google das behoben?
Teilweise, und hier ist Genauigkeit wichtig. Google hat das Security Domain Secret nach der Offenlegung aus den Diagnoseprotokollen von Chrome entfernt. Unit 42 merkt aber an, dass das Geheimnis weiterhin an den Client gesendet wird und im Prozessspeicher von Chrome zugänglich bleibt – dieses Problem ist eingeräumt, nicht gelöst. Schlimmer noch: Die aktuelle Implementierung bietet keine Möglichkeit, diesen Hauptschlüssel zu rotieren oder zu widerrufen, sodass gegenwärtige und künftige Passkeys durch denselben Schlüssel geschützt bleiben. Zum Zeitpunkt der Veröffentlichung hatte Google sich inhaltlich nicht öffentlich geäußert, und die Offenlegung belegt nicht, dass alle drei Angriffswege geschlossen sind.
Sollte ich aufhören, synchronisierte Passkeys zu nutzen, und zu Passwörtern zurückkehren?
Keine Quelle empfiehlt das, und wir auch nicht. Eine Rückkehr zu Passwörtern führt genau die Angriffe wieder ein, die Passkeys beseitigen – Phishing, Wiederverwendung, Credential Stuffing – im Tausch gegen Schutz vor einem Angriff, der voraussetzt, dass Ihr Rechner bereits kompromittiert ist. Nützlicher ist die von J. Wolfgang Goerlich in Computerworld aufgeworfene Unterscheidung: Synchronisierte Passkeys haben ein Risiko der Übertragbarkeit von Anmeldedaten wieder eingeführt, das gerätegebundene Authenticator nicht hatten. Für Ihre wertvollsten Konten ist ein Hardware-Sicherheitsschlüssel die gerätegebundene Option.
Was sollte ein Unternehmen dagegen tun?
Die konkrete Maßnahme, die Forscher und Analysten nennen, liegt auf der Serverseite: userVerification verlangen und das UV-Flag in der Authentifizierungsantwort tatsächlich prüfen. Diese Lücke ist nicht theoretisch – eBay akzeptierte Authentifizierungen ohne Benutzerverifizierung, obwohl userVerification auf required gesetzt war, und hat das nach dem Bericht von Unit 42 behoben. GitHub hat denselben Angriff korrekt abgewiesen, was zeigt, dass eine korrekte Implementierung standhält. Darüber hinaus: die Attestierung des Device-Keys prüfen, ungewöhnliche Passkey-Nutzung überwachen, Endpoint Detection ausrollen und eine ausdrückliche Richtlinie zu synchronisierten gegenüber gerätegebundenen Anmeldedaten festlegen.
Wurde dieser Angriff gegen reale Personen eingesetzt?
Es wurde keine Ausnutzung in freier Wildbahn gemeldet. Biometric Update hielt am 7. August 2026 fest, dass es sich um demonstrative Forschung handelt und dass mit Stand 3. August keine CVE vergeben war. Das ist wichtig für die Reaktion: Das ist ein Grund, zu überprüfen, wie Ihre Konten wiederhergestellt und neu registriert werden, aber kein Grund zur Panik.
