Warum sind Passkeys sicher? — Anhand von Diagrammen erklärt: die Funktionsweise einer Authentifizierung, die kein Geheimnis überträgt

„Schon wieder sind bei einem großen Dienst Passwörter durchgesickert“ – über solche Nachrichten wundert sich niemand mehr. Auch wer jedes Jahr Phishing-Schulungen durchführt, bringt die Zahl der Betroffenen nie auf null. „Passwörter nicht wiederverwenden, sie lang machen, regelmäßiger Wechsel ist … inzwischen nicht mehr nötig“ – selbst die Empfehlungen haben mehrfach die Richtung gewechselt.

Passkeys, die sich in den letzten Jahren rasant verbreitet haben, sind eine Authentifizierungsmethode, die Apple, Google und Microsoft gemeinsam als Antwort auf diese Lage vorantreiben.¹ Meist werden sie als „bequem – Anmeldung per Fingerabdruck oder Gesicht“ vorgestellt, doch darum geht es im Kern nicht. Der eigentliche Wert eines Passkeys besteht darin, dass er die Grundlage der Sicherheit von der „Wachsamkeit des Menschen“ auf die „Struktur des Protokolls“ verlagert.

• Passwörter lecken, weil Benutzer unachtsam sind, also schulen wir sie → Menschen machen immer Fehler
• Trainieren wir Menschen darauf, gefälschte Websites zu erkennen → man kann gefälschte Websites bauen, die nicht zu erkennen sind
• Mit einem Passkey → es gibt von vornherein kein zu sendendes Geheimnis, und auf einer gefälschten Website kann keine Signatur zustande kommen

Dieser Artikel arbeitet mit Diagrammen heraus, warum Passkeys sicher sind, ausgehend davon, was an Passwörtern kaputt ist. Anschließend beantwortet er direkt die naheliegenden Fragen – „Sind synchronisierte Passkeys wirklich sicher?“, „Gibt es Schwachstellen?“ – und schließt mit den praktischen Kernpunkten für die Einführung in Webanwendungen und Windows-Umgebungen.

1. Zunächst das Fazit

Die Gründe, warum Passkeys sicher sind, lassen sich auf drei Punkte zusammenfassen.

1. Auf dem Server existiert kein Geheimnis. Der Server speichert nur den öffentlichen Schlüssel – eine Information, die selbst bei einem Leck nicht missbraucht werden kann. Fließt die gesamte Datenbank ab, gibt es kein „Material für Identitätsdiebstahl“, das ein Angreifer mitnehmen könnte.²
2. Das Geheimnis läuft nicht über das Netzwerk. Bei der Anmeldung wird nur eine Signatur über eine einmalige Zufallszahl (die Challenge) gesendet. Da der private Schlüssel den Authentifikator des Geräts überhaupt nicht verlässt, bringt Abhören oder Weiterleiten an keiner Stelle des Weges das Geheimnis in fremde Hände.²
3. Auf einer gefälschten Website kommt keine Signatur zustande. Ein Passkey ist an die Domäne der Website gebunden, und der Browser erzwingt den Abgleich der Domäne. Selbst wenn ein Benutzer auf eine gefälschte Website hereinfällt, erscheint der Passkey der echten Website erst gar nicht als Option, und selbst wenn eine Signatur irgendwie weitergeleitet würde, scheitert sie bei der Prüfung.³

Diese drei Punkte sind keine unabhängigen Kniffe, sondern Folgen, die sich alle aus einer einzigen Design-Entscheidung ergeben: dem Übergang von einer Authentifizierung, die ein Geheimnis teilt und sendet, zu einer Authentifizierung, die den Besitz eines Geheimnisses durch eine Signatur beweist. Der Reihe nach.

Wie die Begriffe zusammenhängen — Passkey, WebAuthn, FIDO2 und CTAP

In diesem Bereich gibt es viele Begriffe, und je nach Artikel wird ihnen ein unterschiedlicher Umfang zugeschrieben – klären wir daher zunächst nur den Zusammenhang. Ein Passkey ist kein neues Protokoll, sondern ein „Name“, der einer Kombination bestehender Standards gegeben wurde.²¹

Tabelle 1: Ein Passkey ist ein Name, der auf dem Fundament von FIDO2 vergeben wird — kein eigener Standardname

Mit anderen Worten: „Passkeys unterstützen“ bedeutet, in Implementierungssprache übersetzt, „WebAuthn implementieren“. CTAP ist eine Schicht, um die sich Browser und Betriebssystem kümmern, wenn ein externer Authentifikator verwendet wird – wer Webanwendungen entwickelt, kommt damit nie direkt in Berührung.

2. Was an der Passwort-Authentifizierung kaputt ist

Der schnellste Weg, die Sicherheit von Passkeys zu verstehen, besteht darin, die Schwächen von Passwörtern nach „Ort“ zu betrachten. Bei der Passwort-Authentifizierung reist das Geheimnis selbst bei jeder Authentifizierung die gesamte Strecke.

sequenceDiagram
    participant U as Benutzer
    participant B as Browser
    participant S as Server
    Note over U: Trägt das Geheimnis (Passwort) im Kopf<br/>[Schwäche 1] Erratbar, wird wiederverwendet
    U->>B: Gibt das Passwort ein
    Note over B: [Schwäche 2] Lässt sich genauso auf<br/>einer gefälschten Website eingeben (optisch nicht zu unterscheiden)
    B->>S: Sendet das Passwort selbst
    Note over B,S: [Schwäche 3] Das Geheimnis durchläuft die Leitung<br/>Durch TLS geschützt, liegt am Endpunkt aber wieder als Klartext vor
    S->>S: Gleicht es mit dem gespeicherten Hash ab
    Note over S: [Schwäche 4] Die Geheimnisse (Hashes) aller Benutzer sammeln<br/>sich hier an – ein Leck wird zum Ziel für Offline-Brute-Force

Abbildung 1: Bei der Passwort-Authentifizierung existiert das Geheimnis selbst auf der gesamten Strecke

Aus Sicht eines Angreifers ist das eine Struktur mit vielen leicht zu treffenden Zielen.

• Schwäche 1 (der Benutzer): Das Passwort ist nur so stark, wie man es sich merken kann, und wird über mehrere Websites hinweg wiederverwendet. Ein Leck an einer Stelle wirkt sich auf alle Konten aus (Credential-Stuffing-Angriffe).
• Schwäche 2 (der Moment der Eingabe): Wer eine vom Original nicht zu unterscheidende gefälschte Website bereitstellt, dem liefert der Benutzer das Geheimnis von sich aus (Phishing).
• Schwäche 3 (der Weg): TLS macht das Abhören des Weges selbst schwierig, aber das ist bedeutungslos, sobald ein „legitim aussehender Vermittlungspunkt“ dazwischengeschaltet wird (AiTM, siehe unten).
• Schwäche 4 (der Server): Selbst gehasht gespeichert, lässt sich die Datenbank nach einem Leck offline per Brute-Force angreifen. Die schwächsten Passwörter fallen zuerst.

Die traditionelle Antwort, die Multi-Faktor-Authentifizierung, lautet „dann fügen wir eben einen Einmalcode (SMS oder TOTP) hinzu“ – doch das ändert nichts an der Struktur, ein geteiltes Geheimnis zu senden. Bei TOTP teilen sich Server und Authenticator-App denselben Seed (ein Geheimnis), und der erzeugte sechsstellige Code lässt sich am Ende trotzdem vom Benutzer in eine gefälschte Website eingeben. Tatsächlich überwindet AiTM-Phishing (Adversary-in-the-Middle), bei dem eine gefälschte Website in Echtzeit an den echten Server weiterleitet, dies, indem es das Paar aus Passwort und Einmalcode einfach durchreicht. Genau deshalb nennt die CISA (die US-Behörde für Cybersicherheit) als „phishing-resistente MFA“ nur zwei Verfahren – FIDO/WebAuthn und PKI-basierte Authentifizierung wie Smartcards (PIV/CAC) – und stuft FIDO darunter als Goldstandard ein.⁴

Das Problem ist also nicht die „Stärke“ des Passworts, sondern die Struktur selbst, ein Geheimnis zu teilen und es bei jeder Authentifizierung zu senden.

3. Was ein Passkey wirklich ist — Besitz beweisen, ohne das Geheimnis zu senden

Ein Passkey ist ein auf Public-Key-Kryptographie basierender Berechtigungsnachweis, der auf zwei Standards aufbaut – dem WebAuthn des W3C und dem CTAP der FIDO-Allianz (zusammen FIDO2).²¹ Das klingt kompliziert, ist strukturell aber einfach.

flowchart LR
    subgraph DEV["Gerät des Benutzers"]
        AUTH["Authentifikator (Tresor)<br/>Windows Hello / Face ID /<br/>Android-Bildschirmsperre / Sicherheitsschlüssel"]
        SK["Privater Schlüssel<br/>Verlässt diesen Ort nie"]
        BIO["Fingerabdruck, Gesicht, PIN<br/>= öffnet nur die Tresortür<br/>Verlässt das Gerät ebenfalls nie"]
        AUTH --- SK
        BIO -->|"Prüft lokal"| AUTH
    end
    subgraph SRV["Server"]
        PK["Öffentlicher Schlüssel<br/>Selbst bei einem Leck unbedenklich<br/>Rein zur Verifikation"]
    end
    SK -.->|"Mathematisches Paar<br/>(die signierende Seite)"| PK

Abbildung 2: Ein Passkey ist im Kern ein Schlüsselpaar pro Website. Die private Seite verlässt das Gerät nie, und der Server hält nur den öffentlichen Schlüssel zur Verifikation

• Der private Schlüssel ist der Schlüssel, mit dem sich eine Signatur erzeugen lässt. Er wird in einem Authentifikator auf dem Gerät aufbewahrt – Windows Hello, Face ID/Touch ID eines iPhones, die Bildschirmsperre von Android oder ein Sicherheitsschlüssel wie ein YubiKey – und verlässt ihn nicht.
• Der öffentliche Schlüssel ist der Schlüssel, mit dem sich ausschließlich eine Signatur verifizieren lässt, und dieser wird dem Server anvertraut. Da sich der private Schlüssel aus dem öffentlichen rechnerisch nicht zurückgewinnen lässt, ist es eine Information, die bedenkenlos preisgegeben werden kann.
• Biometrische Daten wie Fingerabdruck oder Gesicht werden ausschließlich dazu genutzt, lokal die Tresortür zu öffnen, und verlassen ebenfalls nie das Gerät. Biometrische Daten werden niemals an den Server gesendet.¹

Registrierung: Nur den öffentlichen Schlüssel übergeben

So läuft die Registrierung eines Passkeys bei einer Website ab.

sequenceDiagram
    participant S as Server (example.com)
    participant B as Browser
    participant A as Authentifikator
    S->>B: Registrierungsanfrage (Zufalls-Challenge + Website-Informationen)
    B->>A: Erzeuge einen Schlüssel für diese Website (example.com)
    A->>A: Identitätsprüfung lokal per Fingerabdruck, Gesicht oder PIN
    A->>A: Erzeugt ein neues Schlüsselpaar<br/>Privater Schlüssel bleibt intern gespeichert
    A->>B: Öffentlicher Schlüssel + Credential-ID (das Namensschild des Schlüssels)
    B->>S: Sendet öffentlichen Schlüssel + Credential-ID
    S->>S: Speichert ihn als öffentlichen Schlüssel dieses Kontos
    Note over S: Der Server hat nur „eine Information<br/>erhalten, die selbst bei einem Leck unbedenklich ist“

Abbildung 3: Bei der Registrierung durchläuft nur der öffentliche Schlüssel das Netzwerk und wird auf dem Server gespeichert

Wichtig ist dabei, dass das Schlüsselpaar zu diesem Zeitpunkt an die Domäne der Website (deren RP-ID) gebunden erzeugt wird. Ein für example.com erstellter Passkey lässt sich ausschließlich auf der Website example.com verwenden (da die RP-ID domänenweit gilt, funktioniert er auf Seiten einer Subdomain derselben Domäne wie login.example.com, nicht jedoch auf einer unabhängigen Domäne). Diese Bindung ist das Fundament der weiter unten behandelten Phishing-Resistenz.³

Zudem wird das Schlüsselpaar für jede Website jedes Mal neu erzeugt. Da der Passkey von Website A und der von Website B mathematisch in keinem Zusammenhang stehen, gibt es das Konzept der „Wiederverwendung“ gar nicht erst, und sie lassen sich auch nicht dazu nutzen, einen Benutzer über Websites hinweg zu verknüpfen.

Authentifizierung: Eine einmalige Signatur zurückgeben

So läuft der Vorgang bei der Anmeldung ab. Vergleichen Sie ihn mit der Passwort-Authentifizierung (Abbildung 1).

sequenceDiagram
    participant S as Server (example.com)
    participant B as Browser
    participant A as Authentifikator
    S->>B: Anmeldeanfrage (einmalige Zufalls-Challenge)
    B->>A: Fordert eine Signatur für example.com an
    A->>A: Identitätsprüfung lokal per Fingerabdruck, Gesicht oder PIN
    A->>A: Erstellt eine Signatur mit dem privaten Schlüssel<br/>Bäckt Challenge + Origin + RP-ID-Hash ein
    A->>B: Signatur (nicht der private Schlüssel selbst)
    B->>S: Sendet die Signatur
    S->>S: Verifiziert die Signatur mit dem gespeicherten öffentlichen Schlüssel<br/>Prüft auch Challenge, Origin und RP-ID
    Note over B,S: Nur eine wegwerfbare Signatur durchläuft die Leitung<br/>Selbst gestohlen, ist sie für die nächste Challenge nutzlos

Abbildung 4: Auch bei der Authentifizierung bewegt sich das Geheimnis nicht. Es fließt nur ein „einmaliges Nachweisdokument“

Der Server stellt jedes Mal eine neue Zufallszahl (die Challenge), und der Authentifikator signiert „diese Challenge plus den Origin, den der Browser gerade sieht, plus einen Hash der RP-ID“. Der Server verifiziert die Signatur mit dem gespeicherten öffentlichen Schlüssel und bestätigt dabei, dass die Challenge die von ihm selbst gestellte ist und dass Origin und RP-ID zu seiner eigenen Website gehören.⁵

Als Folge dieses Designs gelten von den drei eingangs genannten Gründen bereits zwei.

• Kein Geheimnis auf dem Server: Gespeichert ist nur der öffentliche Schlüssel. Selbst wenn er ausgelesen wird, kann ein Angreifer daraus keine Signatur erzeugen – anders als bei einem Passwort-Hash gibt es nichts, das man „mitnehmen und knacken“ könnte.
• Kein Geheimnis fließt: Selbst wenn eine Signatur auf dem Weg gestohlen wird, ist die Challenge wegwerfbar und lässt sich nicht wiederverwenden (Replay).

Der verbleibende der drei Gründe – „auf einer gefälschten Website kommt keine Signatur zustande“ – ist der größte Vorzug eines Passkeys. Ihm ist ein eigener Abschnitt gewidmet.

4. Warum Phishing „strukturell“ nicht funktioniert

Phishing gelingt bei Passwörtern, weil sich das echte Geheimnis in eine gefälschte Website eingeben lässt. Menschen können example.com und examp1e.com nicht unterscheiden (besonders wenn sie müde sind), aber das Eingabefeld für das Passwort funktioniert auf beiden Websites gleich.

Bei Passkeys übernimmt diesen Abgleich nicht der Mensch, sondern der Browser, mechanisch. Laut WebAuthn-Spezifikation darf der Browser den Authentifikator nur dann aufrufen, wenn „die Domäne des aktuell angezeigten Origin“ zur „RP-ID des Passkeys“ passt.³ Ein Diagramm zeigt, was in dem Moment passiert, in dem eine gefälschte Website aufgerufen wird.

sequenceDiagram
    participant U as Benutzer
    participant B as Browser
    participant P as Gefälschte Website (examp1e.com)<br/>AiTM-Proxy, der an die echte Seite weiterleitet
    participant S as Echter Server (example.com)
    U->>P: Ruft eine identisch aussehende Anmeldeseite auf
    P->>S: Startet im Hintergrund den echten Anmeldevorgang
    S->>P: Challenge
    P->>B: Reicht die Challenge durch und fordert eine Signatur an
    B->>B: Der aktuelle Origin ist examp1e.com<br/>Der Passkey für example.com kann nicht angeboten werden
    B--xP: Es wird keine Signatur erzeugt (der Benutzer kann gar nicht getäuscht werden)
    Note over B,S: Würde auf irgendeine Weise dennoch eine Signatur erzeugt,<br/>wäre examp1e.com darin eingebrannt,<br/>sodass die Prüfung auf dem echten Server sie zwangsläufig ablehnt

Abbildung 5: AiTM-Phishing überwindet Passwort plus Einmalcode, scheitert bei Passkeys aber schon auf der Stufe der Signatur

Beachten Sie, dass die Verteidigung doppelt greift.

1. Erscheint nicht als Option: Der Browser listet nur Passkeys auf, deren RP-ID zum Origin passt. Auf der gefälschten Domäne erscheint der Passkey der echten Website erst gar nicht als Wahlmöglichkeit, sodass der Benutzer ihn nicht einmal „aus Versehen“ nutzen kann.
2. Die Signatur kommt nicht durch: Das Signierte enthält den vom Browser bestätigten Origin sowie einen Hash der RP-ID. Da der echte Server dies bei der Verifikation abgleicht, wird eine unter einem anderen Origin erzeugte Signatur stets zurückgewiesen.⁵

Der Phishing-Schutz bei Passwörtern beruhte auf menschlicher Anstrengung – „der Benutzer prüft die URL genau“. Bei Passkeys muss der Benutzer die gefälschte Website gar nicht erst erkennen. Das ist die präzise Bedeutung des Begriffs „phishing-resistent“ und der Grund, warum CISA und NIST (die US-Behörde für Standards und Technologie) FIDO/WebAuthn besonders hervorheben.⁴⁶

Fassen wir das bisher Gesagte nach Angriffstechnik zusammen.

Tabelle 2: Vergleich der Widerstandsfähigkeit nach Angriffstechnik. Jedes „○“ bei Passkeys ergibt sich aus der Struktur, nicht aus Betriebsdisziplin oder Aufmerksamkeit

5. Sind „synchronisierte Passkeys“ sicher?

Wer die bisherige Erklärung liest, dem drängt sich natürlich diese Frage auf: „Du hast gesagt, der private Schlüssel verlässt das Gerät nicht – warum lässt sich dann ein auf dem iPhone erstellter Passkey auch auf dem iPad verwenden?“ – eine gute Frage, und die Antwort lautet: „Es gibt zwei Arten von Passkeys.“

Zunächst die Schlussfolgerung als Kurzübersicht. Lesen Sie diesen und den nächsten Abschnitt als Erklärung dafür, warum jede Zeile dieser Tabelle so ist, wie sie ist.

Tabelle 3: Kurzübersicht synchronisierter gegenüber gerätegebundener Passkeys. Welche Variante Sie wählen, hängt davon ab, ob Ihnen „Widerstandsfähigkeit gegen Verlust“ oder „die Fähigkeit, den Verbleib des Schlüssels zu kontrollieren“ wichtiger ist

flowchart TB
    subgraph SYNC["Synchronisierte Passkeys (Standard für Verbraucher)"]
        S1["iCloud-Schlüsselbundverwaltung /<br/>Google-Passwortmanager /<br/>Passwortmanager wie 1Password"]
        S2["Zwischen Geräten desselben Kontos<br/>Ende-zu-Ende-verschlüsselt synchronisiert<br/>Auch der Anbieter kann den Inhalt nicht lesen"]
        S3["Vorteil: robust bei Gerätewechsel und Verlust<br/>Zu beachten: der Schutz des Cloud-Kontos selbst ist erforderlich"]
        S1 --> S2 --> S3
    end
    subgraph BOUND["Gerätegebundene Passkeys"]
        B1["Sicherheitsschlüssel (z. B. YubiKey) /<br/>Windows Hello /<br/>Microsoft Authenticator (Entra ID)"]
        B2["Der private Schlüssel verlässt diese<br/>Hardware physisch nie (geschützt z. B. durch ein TPM)"]
        B3["Vorteil: der Verbleib des Schlüssels ist an einem Ort eindeutig<br/>Zu beachten: mehrere Registrierungen sind für den Verlustfall Pflicht"]
        B1 --> B2 --> B3
    end
    SYNC ~~~ BOUND

Abbildung 6: Synchronisiert gegenüber gerätegebunden. Bei beiden gilt gleichermaßen „der private Schlüssel wird nicht an den Server gesendet“ – nur der Schwerpunkt des Schutzes unterscheidet sich

Synchronisierte Passkeys sind solche, bei denen die iCloud-Schlüsselbundverwaltung oder der Google-Passwortmanager den privaten Schlüssel zwischen Geräten desselben Kontos synchronisiert. Entscheidend ist dabei, dass diese Synchronisierung Ende-zu-Ende-verschlüsselt erfolgt. Sowohl Apple als auch Google erklären ausdrücklich, dass ein Passkey vor der Synchronisierung auf dem Gerät verschlüsselt wird und die Anbieter selbst den Inhalt nicht lesen können.⁷⁸ Der Grundsatz „der private Schlüssel verlässt das Gerät nicht“ wird also präzise zu „der private Schlüssel verlässt das Gerät nicht im Klartext“ abgeschwächt – im Gegenzug gewinnt er Widerstandsfähigkeit gegen Gerätewechsel und Verlust.

Wie diese Abschwächung das Bedrohungsmodell verändert, sollte klar benannt werden. Der zu schützende Ort verlagert sich von „dem Server jeder einzelnen Website“ auf „ein einziges Cloud-Konto“. Gegenüber Datenlecks bei einzelnen Websites und gegenüber Phishing bleibt die Widerstandsfähigkeit unverändert hoch, doch nun wird die Übernahme der Apple-ID oder des Google-Kontos selbst zum Single Point of Failure. Genau deshalb ist es eine Grundvoraussetzung, das Plattformkonto, dem die Passkeys anvertraut sind, mit dem stärksten verfügbaren Schutz zu versehen (eine robuste Bildschirmsperre, aufgeräumte Wiederherstellungsoptionen und, wo möglich, ein physischer Sicherheitsschlüssel). Auch NIST hat im April 2024 mit dem Supplement zu NIST SP 800-63B (Supplement 1: Incorporating Syncable Authenticators Into NIST SP 800-63B) offiziell festgelegt, dass ein solcher synchronisierter Passkey (ein syncable authenticator) bei Erfüllung der Anforderungen die staatliche Stufe AAL2 (Authenticator Assurance Level 2, Vertrauensstufe 2 für Authentifikatoren) erreichen kann. Da der private Schlüssel jedoch exportierbar sein kann, wird festgelegt, dass synchronisierte Authentifikatoren nicht für AAL3 verwendet werden dürfen, das eine hardwareseitig isolierte Umgebung verlangt.⁶

Gerätegebundene Passkeys sind der Typ, bei dem der private Schlüssel die Hardware nicht verlässt. Sicherheitsschlüssel wie YubiKey sind das typische Beispiel, und im Unternehmensumfeld sind auch Passkeys von Microsoft Entra ID (die innerhalb von Microsoft Authenticator erstellt werden) gerätegebunden.⁹ Auch Windows Hello unter Windows schützt den privaten Schlüssel unterhalb des TPM, sofern eines vorhanden ist. Dieser Mechanismus eines „Hardware-Tresors, der den Schlüssel nicht herausgibt“, beruht auf demselben Fundament, das im Artikel zum TPM ausführlich erläutert wurde.

Vielleicht haben Sie sich auch schon einmal gewundert, warum Sie beim „Anmelden im Browser auf dem PC mit dem Passkey des Smartphones“ zum Scannen eines QR-Codes aufgefordert werden. Das ist kein bloßer Bildschirmwechsel, sondern die Hybrid-Methode (die geräteübergreifende Authentifizierung von FIDO), die die physische Nähe von Smartphone und PC über Bluetooth bestätigt. Damit wird ein Angriff verhindert, bei dem ein entfernter Angreifer eine andere Person dazu bringt, per QR-Code eine Anmeldung am eigenen PC des Angreifers zu genehmigen.¹

6. Kein Wundermittel — Schwachstellen „verschwinden“ nicht, sie „wandern“

Bisher wurden die Stärken von Passkeys erläutert, aber ehrlicherweise beseitigen Passkeys Angriffe nicht – sie sind eine Technologie, die Angreifer an schwächere Stellen abdrängt. Ein Diagramm zeigt, wohin Angreifer ausweichen, sobald die Eingangstür der Authentifizierung gehärtet ist.

flowchart LR
    A["Angreifer"]
    G["Authentifizierung selbst<br/>Challenge-Signatur<br/>Gehärtet"]
    R["Kontowiederherstellungsablauf<br/>Meldet „Passkey verloren“ und lässt sich<br/>per SMS oder E-Mail neu einrichten,<br/>um den eigenen Passkey des Angreifers zu registrieren"]
    F["Weiterhin bestehende Fallback-Mittel<br/>Bleiben Passwort- oder SMS-Anmeldung<br/>bestehen, liegt dort das schwächste Glied"]
    C["Cloud-Konto<br/>Bei synchronisierten Passkeys sind Apple-ID/<br/>Google-Konto der Single Point of Failure"]
    SS["Sitzung<br/>Wird das Cookie nach der Anmeldung gestohlen,<br/>spielt die Authentifizierungsmethode keine Rolle"]
    A --x G
    A --> R
    A --> F
    A --> C
    A --> SS

Abbildung 7: Härtet sich die Eingangstür (die Authentifizierung), verlagern sich Angriffe auf Wiederherstellungsablauf, verbliebene Fallback-Mittel, Cloud-Konto und Sitzung

In der Praxis sind vier verbleibende Risiken zu beachten.

1. Weiterhin bestehende Fallback-Mittel werden zum schwächsten Glied. Passkeys „zusätzlich“ nutzbar zu machen, während Passwort oder SMS-Anmeldung bestehen bleiben, gibt Angreifern lediglich diese Alternative. Über das gesamte Konto betrachtet, wird die Phishing-Resistenz durch das Niveau des schwächsten verfügbaren Anmeldeverfahrens begrenzt. Der Kern der Einführung ist nicht das Hinzufügen von Passkeys, sondern der geplante Rückbau und die schrittweise Abschaffung der Fallback-Mittel.
2. Der Wiederherstellungsablauf wird zu einer neuen Angriffsfläche. Dabei behauptet jemand fälschlich, „das Gerät verloren“ zu haben, um über den Support oder eine E-Mail-basierte Neueinrichtung den eigenen Passkey des Angreifers registrieren zu lassen. Social Engineering, das eine gehärtete Authentifizierung umgeht, indem es den Helpdesk täuscht, ist in der Praxis bereits ein gängiges Mittel bei großangelegten Sicherheitsverletzungen. Gerade weil die Authentifizierung gehärtet wurde, kommt es darauf an, wie die Identitätsprüfung im Wiederherstellungsablauf gestaltet ist.
3. Bei synchronisierten Passkeys ist das Cloud-Konto der Single Point of Failure. Wie im vorigen Abschnitt beschrieben. Nötig sind der Schutz des Kontos, dem die Passkeys anvertraut sind, sowie – bei Einsatz in Organisationen – eine Grundsatzentscheidung darüber, zu welchen Plattformen synchronisiert werden darf.
4. Sitzungsdiebstahl wird nicht verhindert. Ein Passkey schützt nur den Moment der Anmeldung; wird das Sitzungscookie nach der Anmeldung per Malware oder XSS gestohlen, spielt die Authentifizierungsmethode keine Rolle. Die Aufgabe der separaten Schicht – Verwaltung von Token-Gültigkeitsdauer, Bindung und Gerätezustand – bleibt bestehen.

Das ist kein Argument gegen die Einführung von Passkeys. Es ist die selbstverständliche Feststellung, dass das Erneuern des Türschlosses nicht auch das Verriegeln der Fenster erledigt. Im Gegenteil: Weil der Ort der Schwachstelle klarer wird, lassen sich Verteidigungsressourcen gezielt auf Wiederherstellungsablauf und Sitzungsverwaltung konzentrieren.

7. Einführung in der Praxis — die WebAuthn-API und Windows-Umgebungen

Zum Schluss die wichtigsten Punkte aus Sicht der einführenden Seite.

Passkey-Anmeldung in den eigenen Webdienst einbauen

Auf der Browserseite genügen zwei Funktionen der WebAuthn-API. Für die Registrierung wird navigator.credentials.create() aufgerufen, für die Authentifizierung navigator.credentials.get().

// Registrierung (Browserseite)
const credential = await navigator.credentials.create({
  publicKey: {
    challenge: challengeFromServer,   // Eine vom Server erzeugte einmalige Zufallszahl
    rp: { id: "example.com", name: "Example" },
    user: { id: userIdBytes, name: "taro@example.com", displayName: "Taro" },
    pubKeyCredParams: [{ type: "public-key", alg: -7 }],  // ES256
    authenticatorSelection: {
      residentKey: "required",        // Macht daraus einen auffindbaren Berechtigungsnachweis (= einen Passkey)
      userVerification: "required",   // Erzwingt die Identitätsprüfung per Biometrie/PIN
    },
  },
});
// Der öffentliche Schlüssel stammt aus credential.response, die Credential-ID
// aus credential.id / credential.rawId auf oberster Ebene. Wie bei der
// Authentifizierung müssen Challenge, Origin und RP-ID auf dem Server
// geprüft werden, bevor die Registrierungsantwort gespeichert wird.

Die Bedeutung der wichtigsten Parameter im Überblick:

Tabelle 4: Die wichtigsten Parameter von navigator.credentials.create()

Hinweis zur Testumgebung: Da die WebAuthn-API nur in einem sicheren Kontext verfügbar ist, schlägt der Aufruf von navigator.credentials auf einer über reines http:// ausgelieferten Seite fehl. Die Ausnahme bildet http://localhost (sowie 127.0.0.1), die als vertrauenswürdige Origins behandelt werden, sodass Sie auf einem Entwicklungsrechner ohne Umstellung auf HTTPS direkt testen können. Allerdings muss die RP-ID die effektive Domäne des Origin (oder eine übergeordnete Domäne) sein, weshalb sich ein unter localhost erstellter Passkey nicht auf der Produktionsdomäne verwenden lässt. Auch ohne Authentifikator zur Hand lässt sich über den Tab „WebAuthn“ der Chrome-Entwicklertools ein virtueller Authentifikator aktivieren, mit dem sich Registrierung und Authentifizierung vollständig durchspielen lassen.

// Authentifizierung (Browserseite)
const assertion = await navigator.credentials.get({
  publicKey: {
    challenge: challengeFromServer,
    rpId: "example.com",
    userVerification: "required",
  },
  // Bietet den Passkey als Autofill-Vorschlag im Anmeldefeld an. Prüfen Sie
  // die Unterstützung vorab mit PublicKeyCredential.isConditionalMediationAvailable()
  // und weichen Sie bei nicht unterstützten Browsern auf einen normalen
  // Aufruf ohne mediation aus.
  mediation: "conditional",
  // (Erfordert autocomplete="username webauthn" am Ziel-<input>)
});
// Die Signatur in assertion.response wird auf dem Server verifiziert

Das Kernstück ist die Verifikation auf der Serverseite. Führen Sie mindestens Folgendes durch.⁵

• Abgleich der Challenge: Handelt es sich um eine selbst ausgestellte, noch nicht verwendete Challenge? Wird sie als wegwerfbar behandelt (Replay-Schutz)? Speichern Sie sie zudem gebunden an die Browsersitzung (den Anmeldeversuch) zum Ausstellungszeitpunkt, und erlauben Sie das Verbrauchen nur bei einer Antwort aus genau dieser Sitzung. Ist dies zu locker gehandhabt, entsteht Raum dafür, dass ein Angreifer eine Signatur über eine an ihn selbst gerichtete Challenge durch den Browser des Opfers einschleust und das Opfer so in das Konto des Angreifers einloggt (Login-CSRF).
• Abgleich des Origin: Ist origin in clientDataJSON der legitime Origin der eigenen Website (der Dreh- und Angelpunkt des Phishing-Schutzes)?
• Abgleich des RP-ID-Hashs: Stimmt rpIdHash in authenticatorData mit dem SHA-256-Hash der eigenen RP-ID überein?
• Prüfung von Zeremonientyp und Flags: Entspricht type in clientDataJSON bei der Authentifizierung webauthn.get und bei der Registrierung webauthn.create? Ist das UP-Flag (User Present) in authenticatorData gesetzt? War eine Identitätsprüfung (User Verification, UV) gefordert, ist dann auch das UV-Flag gesetzt?
• Verifikation der Signatur: Lässt sich die Signatur korrekt mit dem bei der Registrierung gespeicherten öffentlichen Schlüssel verifizieren?
• Bindung an das Konto: Suchen Sie die vorgelegte Credential-ID (und das userHandle) in Ihrer eigenen Datenbank, und stellen Sie die Sitzung für den tatsächlichen Inhaber dieses Berechtigungsnachweises aus. Vertraut man stattdessen bedingungslos einem separat eingegebenen Benutzernamen, entsteht eine Lücke, durch die eine korrekte Signatur jemanden als eine andere Person anmelden lässt.
• Speichern und Vergleichen des Signaturzählers: Speichern Sie signCount aus authenticatorData pro Berechtigungsnachweis, und prüfen Sie, dass der nächste Wert größer ist als der vorherige. Behandeln Sie einen Wert, der dem vorherigen entspricht oder darunterliegt (Gleichstand eingeschlossen), als Hinweis auf einen geklonten Authentifikator. Da viele Implementierungen synchronisierter Passkeys jedoch stets 0 zurückgeben, lassen Sie ausschließlich den Fall 0 gegen 0 als Ausnahme zu.

Diese Verifikation von Hand zu schreiben, ist ein Rezept für Unfälle – verwenden Sie daher eine bewährte Bibliothek (für .NET fido2-net-lib, für Node.js SimpleWebAuthn und Ähnliches). Überlassen Sie die Details der Spezifikation (CBOR-Parsing, Aushandeln des Algorithmus, Challenge-Verwaltung) der Bibliothek und konzentrieren Sie sich selbst auf Speicherung und Verfall der Challenge, die UI zur Verwaltung mehrerer Passkeys sowie die Gestaltung des Wiederherstellungsablaufs – das ist die richtige Aufteilung der Kräfte.

Windows-Umgebungen und interne Systeme

Für die Leserschaft dieser Website – Verantwortliche für Windows-Geschäftssysteme – genügen die folgenden drei Punkte.

• Windows-Clients unterstützen es bereits. Windows 11 unterstützt die Erstellung, Nutzung und Verwaltung von Passkeys über Windows Hello als Authentifikator (Einstellungen > Konten > Passkeys), und der private Schlüssel wird bei vorhandenem TPM hardwaregeschützt.¹⁰ WebAuthn über den Browser (Edge/Chrome) funktioniert auch unter Windows 10.
• In einer Entra-ID-Umgebung die „Passkey = FIDO2-Authentifizierungsmethode“ aktivieren. Microsoft Entra ID unterstützt Sicherheitsschlüssel und Passkeys innerhalb der Microsoft-Authenticator-App (gerätegebunden), und wird über die Authentifizierungsstärke des bedingten Zugriffs „phishing-resistente MFA“ gefordert, lässt sich der Zugriff auf Zielressourcen auf Passkeys und Ähnliches beschränken.⁹ Der Umstieg aus einer Welt von NTLM und Passwortablaufrichtlinien vollzieht sich nicht auf einen Schlag – parallel zur im Artikel zu NTLM und Kerberos behandelten Bestandsaufnahme der Authentifizierungsinfrastruktur ist es daher üblich, phishing-resistente MFA zunächst für Administratorkonten verpflichtend zu machen.
• Der Nutzen ist bei internen Webanwendungen derselbe — HTTPS ist jedoch Voraussetzung. Da die WebAuthn-API nur in einem sicheren Kontext läuft, sind auch bei Intranet-Anwendungen (abgesehen vom localhost während der Entwicklung) die Umstellung auf HTTPS sowie die Bereitstellung interner Domänennamen, die sich als RP-ID eignen, zunächst zu klären. Sind diese Voraussetzungen erfüllt, funktioniert die RP-ID auch gegenüber internen Domänen. Im Sinne des Abschieds vom Passwort-Klebezettel zeigt sich der Effekt bei internen Anwendungen nicht selten sogar schneller als bei nach außen gerichteten Diensten.

8. Zusammenfassung

• Die Schwäche des Passworts liegt nicht in seiner Stärke, sondern in der Struktur, ein Geheimnis zu teilen und es bei jeder Authentifizierung zu senden. Da das Geheimnis beim Benutzer, im Eingabefeld, auf dem Weg und auf dem Server zugleich existiert, gibt es viele Angriffsziele. Auch das Hinzufügen eines Einmalcodes hilft nicht – AiTM-Phishing überwindet ihn, indem es ihn durchreicht.
• Ein Passkey ist ein Schlüsselpaar der Public-Key-Kryptographie pro Website: Dem Server wird nur ein öffentlicher Schlüssel übergeben, der selbst bei einem Leck unbedenklich ist, und bei der Anmeldung wird nur eine Signatur über eine wegwerfbare Challenge gesendet. Auf dem Server existiert kein Geheimnis, und auch auf dem Weg fließt keines.
• Da der vom Browser bestätigte Origin und die RP-ID in die Signatur eingebrannt sind, erscheint der echte Passkey auf einer gefälschten Website nie als Option, und selbst eine weitergeleitete Signatur scheitert bei der Verifikation. Dass der Benutzer die gefälschte Website gar nicht erst erkennen muss, ist der eigentliche Kern von „Phishing-Resistenz“ – die Grundlage der Verteidigung ist von menschlicher Wachsamkeit auf die Struktur des Protokolls übergegangen.
• Synchronisierte Passkeys werden Ende-zu-Ende-verschlüsselt synchronisiert und sind robust gegenüber Gerätewechsel und Verlust. Im Gegenzug verlagert sich der zu schützende Ort auf das Cloud-Konto, weshalb der Schutz der Apple-ID oder des Google-Kontos selbst zur Grundvoraussetzung wird. Unternehmen können sich auch für gerätegebundene Passkeys entscheiden (Sicherheitsschlüssel, Authenticator-Passkeys von Entra ID).
• Passkeys beseitigen Angriffe nicht, sie drängen sie an schwächere Stellen ab. Weiterhin bestehende Passwörter, der Kontowiederherstellungsablauf und Sitzungsdiebstahl bleiben als Angriffsflächen bestehen, und der Kern der Einführung liegt im geplanten Rückbau der Fallback-Mittel und in der Härtung des Wiederherstellungsablaufs.
• Die Implementierung besteht nur aus den beiden Funktionen create / get der WebAuthn-API plus serverseitiger Verifikation. Bauen Sie die Verifikation nicht selbst – überlassen Sie sie einer bewährten Bibliothek und stecken Sie Ihre Kraft in Challenge-Verwaltung, die UI für mehrere Passkeys und das Design der Wiederherstellung.

Verwandte Artikel

• Was ist das TPM unter Windows? — Anhand von Diagrammen erklärt: der „Tresor, der Schlüssel nie herausgibt“ und Measured Boot
• NTLM und Kerberos anhand von Diagrammen erklärt — Warum die Authentifizierung auf NTLM zurückfällt
• Entra-ID-Authentifizierung in WinForms/WPF-Anwendungen einbinden — Ein praxistaugliches Setup mit MSAL.NET und dem WAM-Broker
• Sicherer Umgang mit Anmeldeinformationen in PowerShell — Klartext-Passwörter aus Skripten verbannen
• Eine Mindest-Checkliste für die Sicherheit von Windows-App-Entwicklung
• Womit sollten KMU bei der Sicherheit beginnen? — Ein Rundgang durch die IPA-Leitlinie „Informationssicherheit für KMU“, 4. Auflage

Verwandte Beratungsleistungen

Die KomuraSoft LLC bietet Auftragsentwicklung, die die Unterstützung bei der WebAuthn-Implementierung für Passkey-Anmeldungen in internen Webdiensten, das Design der Einführung phishing-resistenter MFA in Entra-ID-Umgebungen sowie die Einbindung von Authentifizierung in Windows-Geschäftsanwendungen wie WinForms/WPF umfasst.

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Was ist der grundlegende Unterschied zwischen Passkeys und Passwörtern?

Ein Passwort beruht darauf, dass Benutzer und Server dasselbe Geheimnis teilen und dieses Geheimnis bei jeder Anmeldung erneut senden. Weil das Geheimnis überall existiert – im Kopf des Benutzers, im Eingabefeld, auf dem Übertragungsweg und in der Datenbank des Servers –, wird jeder dieser Orte zum Angriffsziel. Ein Passkey verwendet ein Schlüsselpaar der Public-Key-Kryptographie, und der private Schlüssel wird niemals an den Server gesendet. Bei einem gerätegebundenen Passkey verlässt der private Schlüssel den Authentifikator überhaupt nicht; selbst bei einem synchronisierten Passkey verlässt er das Gerät nur in Ende-zu-Ende-verschlüsselter Form. Der Server speichert lediglich den öffentlichen Schlüssel – eine Information, die selbst bei einem Datenleck nicht missbraucht werden kann –, und bei der Anmeldung wird nur eine Signatur über eine einmalige Challenge gesendet. Mit anderen Worten: Das geteilte Geheimnis, die grundlegende Schwäche des Passworts, existiert schlicht nicht. Da zudem für jede Website ein eigenes Schlüsselpaar erzeugt wird, entfällt auch das Konzept der Wiederverwendung.

Werden biometrische Daten (Fingerabdruck, Gesicht) an den Server gesendet?

Nein. Fingerabdruck- oder Gesichtsdaten werden ausschließlich lokal auf dem Gerät verwendet, um „die Tür des Tresors mit dem privaten Schlüssel zu öffnen“, und laut FIDO-Design werden biometrische Daten niemals außerhalb des Geräts übertragen. Der Server erhält lediglich eine Signatur mit gesetztem Flag, dass eine Identitätsprüfung (User Verification) stattgefunden hat – weder der Fingerabdruck selbst noch daraus abgeleitete Merkmale sind darin enthalten. Wo Biometrie nicht genutzt werden kann, lässt sich eine PIN als Ersatz verwenden; auch diese PIN wird, ebenso wie eine Windows-Hello-PIN, nur lokal auf dem Gerät abgeglichen – der entscheidende Unterschied zum Passwort ist, dass sie niemals über das Netzwerk läuft.

Warum sind Passkeys widerstandsfähig gegen Phishing?

Weil der Benutzer eine gefälschte Website konstruktionsbedingt gar nicht erst erkennen muss. Ein Passkey wird an die Domäne einer Website (deren RP-ID) gebunden erstellt, und der Browser bietet ausschließlich Passkeys an, die zur Domäne der gerade angezeigten Website passen. Selbst wer eine täuschend echte gefälschte Domäne aufruft, sieht den Passkey der echten Website gar nicht erst als Option – der Benutzer kann also gar nicht getäuscht werden. Zusätzlich sind in die Signatur der vom Browser bestätigte Origin sowie ein Hash der RP-ID eingebrannt, sodass selbst eine weitergeleitete Signatur bei der Prüfung auf dem echten Server zwangsläufig scheitert. Dass der Unfall, bei dem man wie bei Passwörtern oder SMS-Codes echte Zugangsdaten in eine gefälschte Website eingibt, strukturell gar nicht erst passieren kann, ist der grundlegende Unterschied zu Maßnahmen, die auf Schulung und Aufmerksamkeit setzen.

Werde ich aus meinen Konten ausgesperrt, wenn ich mein Smartphone verliere?

Bei einem synchronisierten Passkey – einem, der in der iCloud-Schlüsselbundverwaltung oder im Google-Passwortmanager gespeichert ist – lässt er sich auf einem neuen Gerät wiederherstellen, das mit derselben Apple-ID beziehungsweise demselben Google-Konto angemeldet ist. Allerdings erfordert die Wiederherstellung des Ende-zu-Ende-verschlüsselten Tresors neben dem Kontopasswort eine zusätzliche Identitätsprüfung, etwa die Eingabe des Bildschirmsperrcodes des vorherigen Geräts – gehen auch diese Wiederherstellungsmittel verloren, ist eine Wiederherstellung womöglich nicht mehr möglich. Wichtig ist daher, nicht alles einem einzigen Smartphone anzuvertrauen. Gerätegebundene Passkeys (Sicherheitsschlüssel, Windows Hello und Ähnliches) teilen das Schicksal des Geräts, weshalb es sich für wichtige Konten empfiehlt, mehrere Passkeys zu registrieren. Viele Dienste erlauben die Registrierung mehrerer Passkeys pro Konto. Zu beachten ist, dass sich das Vorgehen bei Verlust je nach Typ unterscheidet: Bei einem synchronisierten Passkey ist die Kopie auf jedem Gerät dieselbe eine Zugangsdaten – entfernen Sie zunächst über das Plattformkonto das verlorene Gerät oder führen Sie eine Remote-Löschung durch, um die Kopie auf diesem Gerät unbrauchbar zu machen (löschen Sie den Passkey stattdessen in den Kontoeinstellungen des Dienstes selbst, werden die Kopien auf allen Geräten gleichzeitig ungültig). Bei einem gerätegebundenen Passkey lässt sich durch Löschen des Passkeys dieses Authentifikators auf Dienstseite ausschließlich der verlorene Schlüssel deaktivieren. Beim Einsatz in Organisationen ist es wichtig, sowohl „Redundanz, mit der sich Benutzer selbst wiederherstellen können“ als auch „ein Verfahren, mit dem Administratoren den Schlüssel bei Verlust widerrufen“ gemeinsam zu planen.

Haben auch Passkeys Schwachstellen?

Ja. Genauer gesagt verschiebt sich der Ort der Schwachstelle. Weil die Authentifizierung selbst durch Public-Key-Kryptographie gehärtet ist, zielen Angreifer stattdessen auf die schwächere Umgebung. Konkret: Bestehen weiterhin klassische Mittel wie Passwörter oder SMS, bleiben diese das schwächste Glied; es gibt den Trick, über den Missbrauch des Kontowiederherstellungsablaufs einen eigenen Passkey des Angreifers zu registrieren; und bei synchronisierten Passkeys wird die Übernahme des Cloud-Kontos selbst zu einem neuen Single Point of Failure. Zudem lässt sich ein Angriff, der das Sitzungscookie nach der Anmeldung stiehlt, durch einen Passkey nicht verhindern – nicht verwandte Bedrohungen verschwinden also nicht einfach. Bei der Einführung muss daher nicht nur „Passkeys ergänzen“ berücksichtigt werden, sondern auch die Härtung des Wiederherstellungsablaufs und der geplante Rückbau von Fallback-Mitteln.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.