SpecterOps<\/a> verdeutlicht die Tragweite dieses Problems. Eine der zentralen Erkenntnisse: Malware muss nicht zwingend einen privaten Schl\u00fcssel extrahieren. Eine schadhafte Windows-Anwendung kann die legitime WebAuthn-Infrastruktur auffordern, eine signierte Assertion zu generieren. Der Nutzer sieht eine vermeintlich vertrauensw\u00fcrdige Windows-Authentifizierungsoberfl\u00e4che, schlie\u00dft die Verifikation ab \u2013 und der Angreifer erh\u00e4lt die daraus resultierende Assertion. Der private Schl\u00fcssel verlie\u00df nie seinen gesch\u00fctzten Ort. Die Kryptografie wurde nicht geknackt. Dennoch wurde der gesamte Authentifizierungsprozess erfolgreich manipuliert. Diese Unterscheidung ist zentral f\u00fcr das Verst\u00e4ndnis des neuen Passkey-Bedrohungsmodells.<\/p>\nSogar die Passkey-Aufforderung ist eine Angriffsfl\u00e4che<\/h2>\n
Mehrere der 39 dokumentierten Techniken zielen direkt auf die Benutzeroberfl\u00e4che 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\u00f6hnen sich an Authentifizierungsaufforderungen. Wird die Authentifizierung zu einer routinem\u00e4\u00dfigen visuellen Interaktion, k\u00f6nnen Angreifer diese Interaktionen herstellen, wiederholen, tarnen oder strategisch timen. Die Phishing-Resistenz auf der kryptografischen Protokollebene garantiert keine T\u00e4uschungsresistenz auf den dar\u00fcberliegenden Schichten des Betriebssystems, des Browsers, der Anwendung und der Benutzeroberfl\u00e4che.<\/p>\n
Teilbare Passkeys erweitern die Angriffsfl\u00e4che massiv<\/h2>\n
Das Angriffspotenzial w\u00e4chst signifikant, sobald Passkeys geteilt, synchronisiert, exportiert, wiederhergestellt oder zwischen Ger\u00e4ten verschoben werden k\u00f6nnen. Die \u00f6ffentlich bekannte Liste umfasst nun Techniken wie die Kompromittierung synchronisierter Vaults, die \u00dcbernahme von Apple- oder Google-Konten, Cloud-Recovery-\u00dcbernahmen, den Diebstahl oder die Kompromittierung von Mobiltelefonen, mobile Malware, gerootete Ger\u00e4te, die Manipulation hybrider Authentifizierung, den Diebstahl von KeePassXC- oder Bitwarden-Exporten, b\u00f6sartige Browsererweiterungen sowie Angriffe auf CTAP- und Bluetooth-Kommunikation.<\/p>\n
Dies ist im Kern kein kryptografisches Problem, sondern ein architektonisches. Sobald ein Credential zwischen Ger\u00e4ten wechseln, \u00fcber ein Cloud-Konto synchronisiert, aus einem Vault exportiert, mit einer anderen Identit\u00e4t wiederhergestellt oder \u00fcber einen anderen Prozess zur\u00fcckgesetzt werden kann, erstreckt sich die Sicherheitsgrenze weit \u00fcber den urspr\u00fcnglichen Authenticator hinaus. Ein Angreifer muss FIDO2 nicht mehr besiegen \u2013 er muss lediglich eine ausreichend vertrauensw\u00fcrdige Komponente im umgebenden \u00d6kosystem kompromittieren. Ein synchronisierter Passkey kann daher extrem starke Kryptografie nutzen und dennoch die Schw\u00e4chen des Telefons, des Betriebssystems, des Passwortmanagers, des Cloud-Kontos, des Browsers, des Recovery-Prozesses und des Synchronisationssystems erben, die f\u00fcr seine Verwaltung verantwortlich sind.<\/p>\n
Enrollment und Recovery schaffen eine weitere Einfallst\u00fcr<\/h2>\n
Einige der folgenreichsten Angriffe stehlen gar keinen existierenden Passkey. Sie registrieren einfach einen neuen. Zu den publizierten Techniken geh\u00f6ren Shadow Passkeys, Enrollment-Vishing, die Registrierung eines Angreifer-Telefons, die kontrollierte Passkey-Registrierung durch den Angreifer, Helpdesk-\u00dcbernahmen, der Missbrauch tempor\u00e4rer Credentials, SIM-basiertes Recovery, Reverse-Vishing und Migration-Pretext-Angriffe.<\/p>\n
Stellen Sie sich vor, ein Angreifer erlangt die Kontrolle \u00fcber ein Mitarbeiterkonto, das ausreicht, um eine legitime Passkey-Registrierung zu initiieren. Statt das bestehende Credential des Mitarbeiters zu extrahieren, registriert der Angreifer ein v\u00f6llig neues Credential auf einem von ihm kontrollierten Ger\u00e4t. Nichts wurde geknackt. Nichts wurde vom legitimen Authenticator gestohlen. Der legitime Dienst selbst erstellt ein perfekt g\u00fcltiges Credential f\u00fcr den Widersacher. Dies f\u00fchrt zu einem zunehmend wichtigen Identit\u00e4tsprinzip: Phishing-resistente Authentifizierung ist unzureichend, wenn Enrollment, Ersatz, Recovery und Ger\u00e4teregistrierung nicht demselben Standard entsprechen.<\/p>\n
Dedizierte biometrische Hardware ver\u00e4ndert die Angriffsfl\u00e4che grundlegend<\/h2>\n
Dedizierte biometrische Hardware n\u00e4hert sich dem Problem fundamental anders als Passkeys auf Allzweckger\u00e4ten. Ein speziell f\u00fcr diesen Zweck entwickelter biometrischer Authenticator kann das private Credential in sicherer Hardware speichern \u2013 ohne Cloud-Synchronisation, ohne Exportmechanismus und ohne Passwortmanager, der das Credential zwischen Ger\u00e4ten bewegt. Die Authentifizierung kann sowohl einen Live-Fingerabdruck direkt auf dem Authenticator als auch die physische N\u00e4he zum anfragenden Endpunkt erfordern. Ein dedizierter Authenticator ben\u00f6tigt zudem kein herk\u00f6mmliches Allzweck-Betriebssystem, keinen App-Store, keinen Browser und keinen Bildschirm.<\/p>\n
Diese Unterscheidung eliminiert enorme Teile der Angriffsfl\u00e4che. Es gibt keine Drittanbieter-Anwendungen, die ein Angreifer durch schadhafte Versionen ersetzen k\u00f6nnte. Auf dem Authenticator k\u00f6nnen keine sch\u00e4dlichen Apps installiert werden. Es gibt kein Browser-Erweiterungs-\u00d6kosystem, das kompromittiert werden k\u00f6nnte. Es gibt keinen Bildschirm, auf dem Malware eine tr\u00fcgerische Authentifizierungsoberfl\u00e4che pr\u00e4sentieren k\u00f6nnte. Der Authenticator f\u00fchrt eine sehr kleine Anzahl sicherheitsspezifischer Funktionen aus \u2013 und sonst nichts. Dies ver\u00e4ndert die \u00d6konomie eines Angriffs drastisch. Statt eine riesige Allzweck-Computerumgebung zu kompromittieren, steht der Angreifer einer eng kontrollierten Hardware gegen\u00fcber, die speziell daf\u00fcr entwickelt wurde, kryptografische Credentials zu sch\u00fctzen und die biometrische Identit\u00e4t zu verifizieren.<\/p>\n
Gleichzeitig wird der Authentifizierungsprozess weitaus resistenter gegen Manipulation durch Mitarbeiter. Ein Mitarbeiter kann \u00fcberredet werden, eine Website zu besuchen, einen Telefonanruf zu beantworten oder Anweisungen eines angeblichen Support-Mitarbeiters zu befolgen. Social Engineering<\/a> kann jedoch keine sch\u00e4dliche Anwendung auf Hardware installieren, die keine gew\u00f6hnlichen Anwendungen ausf\u00fchrt. 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.<\/p>\nDie korrekte Dienstkonfiguration ist entscheidend<\/h2>\n
Dedizierte Hardware allein reicht nicht aus. Der relying Service muss so konfiguriert sein, dass das Sicherheitsmodell erhalten bleibt. F\u00fcr sensible Unternehmensumgebungen sollten Authentifizierung und Enrollment auf zugelassene Authenticator-Klassen beschr\u00e4nkt werden. Die relying Party sollte die Authenticator-Identit\u00e4t validieren, die Benutzerverifikation erzwingen, Challenges und Sessions ordnungsgem\u00e4\u00df validieren, angemessene Signaturz\u00e4hler-Schutzma\u00dfnahmen verwenden und verhindern, dass schw\u00e4chere Methoden zu fallback-Authentifizierungspfaden werden. Enrollment und Recovery verdienen besondere Aufmerksamkeit: Das Hinzuf\u00fcgen eines neuen Authenticators sollte den Nachweis durch einen bereits autorisierten Authenticator erfordern \u2013 und nicht lediglich den Nachweis der Kontrolle \u00fcber ein Konto durch einen schw\u00e4cheren Recovery-Kanal.<\/p>\n
Was die 39 Angriffsmethoden wirklich bedeuten<\/h2>\n
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 \u2013 weil es erheblich schwieriger ist, eine korrekt implementierte kryptografische Hardware direkt zu besiegen. Das sollte Sicherheitsverantwortlichen zeigen, wo die n\u00e4chste Identit\u00e4tsgrenze gezogen werden muss. F\u00fcr hochwertige Unternehmensidentit\u00e4ten sollten Credentials nicht frei \u00fcber Consumer-Ger\u00e4te und Cloud-\u00d6kosysteme 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 \u00fcber die Authentifizierung bis zum Recovery, entfernt praktisch die gesamte umgebende Angriffsfl\u00e4che \u2013 bevor ein Angreifer \u00fcberhaupt die Gelegenheit erh\u00e4lt, sie zu nutzen.<\/p>\n","protected":false},"excerpt":{"rendered":"
Die Sicherheitsversprechen der Passkey-Authentifizierung schienen zun\u00e4chst bahnbrechend: Ende-zu-Ende-Verschl\u00fcsselung durch Public-Key-Kryptografie, private Schl\u00fcssel, die niemals den Server verlassen, und ein effektiver Schutz vor Phishing-Angriffen. Doch die Realit\u00e4t der Bedrohungslandschaft hat sich rasant ver\u00e4ndert \u2013 inzwischen sind mindestens 39 \u00f6ffentlich dokumentierte Methoden bekannt, die diese Authentifizierung kompromittieren k\u00f6nnen, ohne dass die zugrundeliegende Kryptografie gebrochen werden muss. Das […]<\/p>\n","protected":false},"author":5,"featured_media":55151,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"fifu_image_url":"https:\/\/cards.overcentral.com\/cards\/de\/51173.png","fifu_image_alt":"39 Methoden kompromittieren Passkey-Authentifizierung","footnotes":""},"categories":[6671],"tags":[],"class_list":["post-51173","post","type-post","status-publish","format-standard","has-post-thumbnail","category-scherheit"],"fifu_image_url":"https:\/\/cards.overcentral.com\/cards\/de\/51173.png","fifu_image_alt":"39 Methoden kompromittieren Passkey-Authentifizierung","_links":{"self":[{"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/posts\/51173","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/comments?post=51173"}],"version-history":[{"count":2,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/posts\/51173\/revisions"}],"predecessor-version":[{"id":51176,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/posts\/51173\/revisions\/51176"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/media\/55151"}],"wp:attachment":[{"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/media?parent=51173"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/categories?post=51173"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/tags?post=51173"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}