Warum Passkeys sicher sind — Funktionsweise, Synchronisierung und Hinweise bei Geräteverlust

„Sie können sich mit dem Fingerabdruck anmelden, also ist es sicher.“ So werden Passkeys manchmal vorgestellt, doch der Kern ihrer Sicherheit ist nicht der Fingerabdruck oder das Gesicht selbst. Er liegt darin, per Signatur zu beweisen, dass Sie den Schlüssel für diese Site besitzen, ohne den privaten Schlüssel an den Anmeldedienst zu übergeben.¹

Nehmen Sie das jedoch als „ein Passkey kann nie übernommen werden“ oder „der private Schlüssel verlässt das Telefon unter keinen Umständen“, treffen Sie bei Synchronisierung und Geräteverlust die falschen Entscheidungen. Dass der Anmeldemechanismus härter wird, und dass Gerät, Wiederherstellungsverfahren und die Sitzung nach der Anmeldung von selbst sicher werden, sind verschiedene Dinge.

Dieser Artikel beginnt beim Unterschied zu Passwörtern, zeigt Registrierung und Anmeldung und arbeitet dann ab, warum Passkeys Phishing standhalten, worin sich synchronisierte und gerätegebundene Passkeys unterscheiden und was bei Geräteverlust zu tun ist. Die zweite Hälfte behandelt die Prüfpunkte bei der Einführung in den eigenen Webdienst oder in Windows-Geschäftssysteme.

In der Abbildung kennzeichnet eine durchgezogene Linie eine stets geltende Beziehung und eine gestrichelte Linie eine bedingte (die Bedingungen stehen bei jeder Beziehung auf der Detailseite). Die vollständige Liste der Beziehungen (38 insgesamt, mit Beleg und Sicherheitsgrad) und die Definitionen der wichtigsten Konzepte sind auf der Detailseite der Wissenskarte (auf Japanisch) zusammengestellt. Daten: JSON-LD / Turtle

1. Es gibt drei Gründe, warum Passkeys sicher sind

Ein Passkey ist eine Anmeldeinformation auf Basis der Public-Key-Kryptographie, mit der man sich statt mit einem Passwort anmelden kann. Vom bei der Registrierung erzeugten Schlüsselpaar bleibt der private Schlüssel unter Kontrolle der nutzenden Person, der öffentliche Schlüssel wird beim Dienst registriert. Im Web nutzen Registrierung und Authentifizierung die Standard-API WebAuthn.¹²

flowchart TB
        accTitle: Drei Schwachstellen der Authentifizierung, die Passkeys ändern
        accDescr: Übergabe eines Geheimnisses, Wiederverwendung einer Antwort und Verwechslung der Nutzungsstelle werden jeweils durch einen anderen Mechanismus behandelt.
        A["Anmeldung mit einem Passkey"] --> B["Eine Signatur zurückgeben, nie den privaten Schlüssel"]
        A --> C["Die Challenge abgleichen und verbrauchen"]
        A --> D["RP-ID und Origin prüfen"]
        B --> E["Der öffentliche Schlüssel allein kann keine Signatur fälschen"]
        C --> F["Eine frühere Antwort lässt sich nicht wiederverwenden"]
        D --> G["Auf einer nicht zugehörigen gefälschten Site unbrauchbar"]

Abbildung 1: Die Stärke eines Passkeys liegt in der Kombination aus Kryptographie, einmaliger Anforderung und Beschränkung der Nutzungsstelle.

Wenn dieser Artikel sagt, der private Schlüssel werde „nicht gesendet“, ist das Ziel der Server des Dienstes, bei dem Sie sich anmelden. Bei einem synchronisierten Passkey gibt es einen getrennten Weg, der den privaten Schlüssel verschlüsselt speichert und repliziert. Diese Trennung klärt, was „das Geheimnis nicht senden“ bedeuten kann, obwohl der Schlüssel in die Cloud synchronisiert.

Der Server hält außerdem mehr als den öffentlichen Schlüssel: den Identifikator der Anmeldeinformation, die Zuordnung zum Konto, Sitzungsinformationen und Ähnliches. „Mit dem öffentlichen Schlüssel allein kann man sich nicht ausgeben“ und „die Datenbank muss nicht geschützt werden“ sind nicht dieselbe Aussage.²

2. Was lange Passwörter und Einmalcodes übrig lassen

Bei gewöhnlicher Passwortauthentifizierung sendet die nutzende Person das eingegebene Passwort über eine TLS-geschützte Verbindung an den Server, und der Server vergleicht es mit einem gespeicherten Hash oder Ähnlichem. Ein angemessen gesalzener Hash mit ausreichendem Rechenaufwand erschwert wiederholte Rateangriffe nach einem Abfluss der gespeicherten Daten. Zufällige, lange, nicht wiederverwendete Passwörter haben ebenfalls einen Sinn.³

Wird dasselbe Passwort bei mehreren Diensten wiederverwendet, kann Credential Stuffing — das Ausprobieren eines an einer Stelle abgeflossenen Paars aus ID und Passwort auf anderen Sites — den Schaden auf andere Konten ausweiten. Ein langes Passwort stoppt diese Ausweitung nicht, wenn es wiederverwendet wird.⁴

Trotzdem bleibt: das richtige Passwort kann der falschen Gegenstelle übergeben werden. Tippen Sie Ihr echtes Passwort in eine von der angreifenden Partei eingerichtete Site, erreicht der Wert die angreifende Partei, auch wenn das TLS-Zertifikat dieser Site gültig ist. TLS ist nicht gebrochen; Sie haben verwechselt, mit wem Sie sicher sprechen.

sequenceDiagram
        accTitle: TLS allein verhindert die Eingabe auf einer gefälschten Site nicht
        accDescr: Passwort und Code, die jemand in eine gefälschte Site eingibt, erreichen deren Betreiber auch über eine verschlüsselte Verbindung.
        participant U as Nutzer
        participant P as Gefälschte Site
        participant S as Echter Dienst
        U->>P: Gibt das echte Passwort ein
        P->>S: Leitet das eingegebene Passwort weiter
        S-->>P: Fordert zusätzliche Authentifizierung
        P-->>U: Fordert einen Einmalcode
        U->>P: Gibt den Code ein
        P->>S: Leitet den Code weiter, solange er gültig ist
        S-->>P: Stellt bei erfolgreicher Prüfung eine Sitzung aus

Abbildung 2: Skizze von AiTM-Phishing, das Passwort und Code in Echtzeit weiterleitet.

TOTP ist ein Verfahren, bei dem Authenticator-App und Server einen gemeinsamen Seed halten und aus der aktuellen Zeit einen Code erzeugen. Der Seed selbst wird bei jeder Anmeldung nicht gesendet. Der eingegebene Code ist jedoch nicht an die Domäne der echten Site gebunden, daher bleibt im Gültigkeitsfenster Raum, ihn von einer gefälschten Site weiterzuleiten. SMS-Codes haben dasselbe Problem, dass sie in eine gefälschte Site eingegeben werden können.³

Das heißt nicht, Mehr-Faktor-Authentifizierung sei sinnlos. Sie blockiert mehr Angriffe als eine reine Passwortanmeldung. Darüber hinaus gibt es gegen Angriffe, die die manuelle Codeeingabe treffen, einen Grund, zu phishing-resistenter Authentifizierung wie FIDO/WebAuthn überzugehen.⁵

Starke Passwörter in einem Passwortmanager zu erzeugen und sie nur auf der richtigen Domäne automatisch einzufügen, ist ebenfalls wirksam. Die nutzende Person kann das Passwort aber kopieren und in ein anderes Feld einfügen. Bei einem Passkey lässt sich diese Beschränkung der Nutzungsstelle nicht allein durch eigenes Handeln aufheben.

3. Was bei Registrierung und Anmeldung tatsächlich übertragen wird

Die Registrierung erzeugt ein Schlüsselpaar und bindet es an das Konto

Beim Umgang mit einem Passkey gibt es grob drei Rollen: die Relying Party (RP) auf der Dienstseite, Browser und Betriebssystem, die WebAuthn bereitstellen, und den Authenticator, der den Schlüssel erzeugt und nutzt. Zu den Authenticators gehören solche, die mit Betriebssystemfunktionen und Anmeldeinformations-Managern zusammenarbeiten, und externe FIDO2-Sicherheitsschlüssel. Der Abgleich von Gesicht oder Fingerabdruck ist der Schritt, der ihre Nutzung erlaubt.²⁶

sequenceDiagram
        accTitle: Ablauf der Passkey-Registrierung
        accDescr: Auf die Registrierungsanforderung wird ein Schlüsselpaar erzeugt, und der Dienst prüft die Registrierungsantwort und bindet öffentlichen Schlüssel und Anmeldeinformations-ID an das Konto.
        participant S as Dienst
        participant B as Browser und OS
        participant A as Authenticator
        S->>B: Challenge und Kontoinformationen
        B->>B: Prüft die Nutzungsstelle
        B->>A: Anforderung, eine Anmeldeinformation zu erzeugen
        A->>A: Nutzerverifikation und Erzeugung des Schlüsselpaars
        A-->>B: Öffentlicher Schlüssel, Anmeldeinformations-ID und weiteres
        B->>S: Sendet die Registrierungsantwort
        S->>S: Prüft die Registrierungsantwort
        S->>S: Registriert die Anmeldeinformation am Konto

Abbildung 3: Registriert wird nicht nur der öffentliche Schlüssel, sondern eine Antwort mit Identifikator und Prüfdaten. Der private Schlüssel wird dem Anmeldedienst nicht gesendet.

Die Credential-ID identifiziert, welcher Passkey welcher ist. Der Server speichert sie zugeordnet zum öffentlichen Schlüssel und zum Konto. Wenn Sie einem bestehenden Konto einen neuen Passkey hinzufügen, bestätigen Sie zuerst über ein bestehendes Verfahren, dass es sich um die nutzende Person dieses Kontos handelt, und authentifizieren Sie bei Bedarf erneut. Das Zielkonto darf nie allein aus einem vom Browser gesendeten Benutzernamen entschieden werden.⁶⁷

In der Regel entsteht bei der Registrierung bei einem anderen Dienst oder einem anderen Konto ein eigenes Schlüsselpaar, sodass niemand etwas Entsprechendes zur Passwortwiederverwendung tun muss. Das ist jedoch kein Mechanismus, der Korrelation über andere Angaben wie eine E-Mail-Adresse verhindert, und es bedeutet nicht, „ein Passkey macht anonym“.

Die Anmeldung gibt eine Signatur über die aktuelle Anforderung zurück

Bei der Anmeldung stellt der Server eine Challenge aus, einen schwer vorhersagbaren Zufallswert. Der Authenticator erzeugt mit dem privaten Schlüssel eine Signatur, und der Browser gibt sie an den Server zurück. Der Server prüft sie mit dem registrierten öffentlichen Schlüssel und bestätigt, dass es eine korrekte Antwort auf die diesmal ausgestellte Anforderung ist.⁶

sequenceDiagram
        accTitle: Ablauf der Passkey-Anmeldung
        accDescr: Der Authenticator erzeugt eine an die aktuelle Anforderung gebundene Signatur, und der Server prüft Signatur, Challenge, Nutzungsstelle und Konto.
        participant S as Dienst
        participant B as Browser und OS
        participant A as Authenticator
        S->>B: Eine ungenutzte Challenge und die RP-ID
        B->>B: Prüft, dass die vorgesehene Site gültig ist
        B->>A: RP-ID und Hash der Daten
        A->>A: Bestätigt mit Biometrie oder PIN
        A->>A: Signiert mit dem privaten Schlüssel
        A-->>B: Authenticator-Daten und Signatur
        B->>S: Credential-ID und Authentifizierungsantwort
        S->>S: Prüft Antwort und Konto
        S-->>B: Stellt nur bei Erfolg eine Sitzung aus

Abbildung 4: Die Anmeldeantwort ist der Nachweis, den privaten Schlüssel zu besitzen, nicht der private Schlüssel selbst.

Genauer ist die bei der Authentifizierung signierte Datenmenge die folgende. || bezeichnet die Verkettung von Bytefolgen.⁸

Signed data = authenticatorData || SHA-256(clientDataJSON)

clientDataJSON:
  type       webauthn.get for authentication
  challenge  the challenge the server issued
  origin     the origin of the caller

authenticatorData:
  rpIdHash   SHA-256 hash of the RP ID
  flags      results such as user presence and user verification
  signCount  signature counter

„Die Challenge signieren“ ist eine Kurzform, um das Gesamtbild zu erfassen. In der Praxis gehen auch Nutzungsstelle und Zustand des Authenticators in die Signaturprüfung ein. Die Arbeitsteilung zählt ebenfalls: Der Authenticator liest die Webseite nicht, um den Origin zu bestimmen; er empfängt den Hash der Client-Daten, die der Browser gesammelt hat.

flowchart TB
        accTitle: Daten, die bei der Authentifizierung in die Signatur gebunden werden
        accDescr: Der Hash der Client-Daten einschließlich Challenge und Origin wird mit den Authenticator-Daten einschließlich Hash der RP-ID verkettet und das Ergebnis signiert.
        A["Challenge, Origin und weiteres"] --> B["Hash von clientDataJSON"]
        C["Hash der RP-ID, Flags und weiteres"] --> D["authenticatorData"]
        B --> E["Authenticator-Daten und Hash verketten"]
        D --> E
        E --> F["Mit dem privaten Schlüssel signieren"]

Abbildung 5: Nicht nur die Challenge, sondern auch Nutzungsstelle und Zustand des Authenticators gehen in die Signaturprüfung ein.

Eine frühere Signatur lässt sich nicht wiederverwenden, aber nicht weil die Signatur selbst zeitlich abläuft. Es liegt daran, dass der Server die Challenge an einen Anmeldeversuch bindet, eine Frist setzt und eine bereits verwendete Anforderung ablehnt. Eine erfolgreiche Prüfung der Public-Key-Signatur allein ist keine hinreichende Bedingung, eine Anmeldung zu erlauben.

4. Warum selbst eine pixelgenaue gefälschte Site Ihren Passkey nicht nutzen kann

RP-ID und Origin haben unterschiedliche Rollen

Die RP-ID ist der Domänenname, der den Geltungsbereich einer Anmeldeinformation bestimmt, und wird üblicherweise etwa als example.com angegeben. Der Origin ist dagegen die Kombination aus Schema, Host und Port. Eine denkbare Anordnung ist https://login.example.com als Origin und example.com als RP-ID.⁹

Unter der üblichen Domänenbeziehungsprüfung darf eine Seite auf login.example.com example.com als RP-ID angeben. Eine Seite auf der nicht zugehörigen examp1e.com kann jedoch nicht example.com angeben und den Passkey der echten Site nutzen. Was der Browser prüft, ist die Beziehung zur Nutzungsstelle, nicht ob beide ähnlich aussehen.

flowchart TB
        accTitle: Wie die RP-ID die Nutzungsstelle einer Anmeldeinformation beschränkt
        accDescr: Eine Seite mit legitimer Domänenbeziehung und eine nicht zugehörige gefälschte Site erhalten vom Browser unterschiedliche Entscheidungen, wenn sie die echte RP-ID anfordern.
        A["example.com als RP-ID angeben"] --> B{"Wo ist der Aufrufer"}
        B -->|"login.example.com"| C["Erfüllt die Bedingung der Domänenbeziehung"]
        B -->|"examp1e.com"| D["Als nicht zugehörige Domäne abgelehnt"]
        C --> E["Mit dem passenden Passkey authentifizieren"]
        E --> F["Der Server prüft außerdem, dass es ein erlaubter Origin ist"]
        D --> G["Der Passkey der echten Site lässt sich nicht nutzen"]

Abbildung 6: Sowohl die Beschränkung der Nutzungsstelle durch den Browser als auch die Origin-Prüfung des Servers tragen die Phishing-Resistenz.

Auch serverseitig prüfen Sie, dass der mit der Signatur zurückgegebene origin ein erlaubter Origin ist und dass rpIdHash der Hash der erwarteten RP-ID ist. Ein Schlüssel, der unter der eigenen RP-ID einer gefälschten Site erzeugt wurde, oder eine Antwort von einem nicht erlaubten Origin darf nie als Authentifizierung für ein echtes Konto angenommen werden.⁸

Beachten Sie, dass WebAuthn Level 3 auch Related Origin Requests kennt, mit denen dieselbe RP-ID von einem anderen Origin genutzt werden kann, den der Dienst ausdrücklich zugeordnet hat. Die Behauptung „ohne exakte Übereinstimmung des Hostnamens nie nutzbar“ ist ebenfalls ungenau. Wichtig ist, die Nutzung der Anmeldeinformation im vom Dienst genehmigten Rahmen zu halten. Auch bei Related Origins geht es nicht darum, die Allowlist des Servers unbegrenzt zu erweitern.⁹

„Phishing-Resistenz“ ist nicht Resistenz gegen jeden Betrug

Alles bisher Erklärte setzt voraus, dass Browser, Betriebssystem und Authenticator vertrauenswürdig sind und der Server die nötige Prüfung durchführt. Kompromittierung der echten Site, Malware auf dem Gerät und ein schwaches Kontowiederherstellungsverfahren löst WebAuthn allein nicht.

Eine gefälschte Site kann mit „Passkeys sind nicht verfügbar, bitte Passwort und SMS-Code eingeben“ auf einen anderen Anmeldeweg lenken. Passkeys sind stark gegen den Bruch, echte Anmeldeinformationen einer gefälschten Site zu übergeben; sie bedeuten nicht, dass niemand mehr aufpassen muss.⁵

5. Fingerabdruck, Gesicht und PIN sind keine an den Server gesendeten Passwörter

Fingerabdruck oder Gesicht werden bei der Passkey-Nutzung verlangt, damit das Gerät bestätigt, dass die berechtigte Person den Vorgang mit dem privaten Schlüssel genehmigt. Dieser Schritt heißt User Verification (UV). Eine WebAuthn-Authentifizierungsantwort trägt weder ein Fingerabdruckbild noch einen Gesichtsmerkmalvektor zum Anmeldedienst.¹²

flowchart TB
        accTitle: Lokale Nutzerverifikation auf dem Gerät und Signaturprüfung beim Dienst
        accDescr: Fingerabdruck, Gesicht und PIN dienen auf der Nutzerseite dazu, die Schlüsselverwendung zu erlauben; der Dienst prüft Signatur und Verifikationsergebnis, nicht biometrische Daten.
        A["Mit Fingerabdruck, Gesicht oder PIN bestätigen"] --> B["Authenticator erlaubt die Nutzung des privaten Schlüssels"]
        B --> C["Signierte Authentifizierungsantwort erzeugen"]
        C --> D["Dienst prüft sie mit dem öffentlichen Schlüssel"]
        D --> E["Dienst prüft außerdem das angeforderte Ergebnis der Nutzerverifikation"]

Abbildung 7: Entsperren des Geräts und Authentifizierung gegenüber dem Dienst greifen ineinander, aber der Server gleicht weder Fingerabdruck noch PIN ab.

Reicht eine PIN zur Nutzung, kann das wie ein Passwort wirken. Der Unterschied ist, wogegen diese PIN abgeglichen wird. Die PIN hier erlaubt die Nutzung des Authenticators; sie ist kein Passwort, das eine Website für jede Person hält und bei jeder Anmeldung empfängt. Ein gut entworfener Authenticator begrenzt außerdem die Zahl falscher Eingaben.³

Ist das Gerät gestohlen und der Entsperrweg bekannt, steigt dennoch das Risiko, dass eine angreifende Partei den Passkey nutzen kann. Der Wechsel zur Gesichtserkennung macht ein einfaches Gerätekennwort nicht akzeptabel. Außerdem ist User Presence (UP), das etwa eine Berührung des Bildschirms anzeigt, ein anderes Flag als UV durch Biometrie oder PIN. Implementierende fordern die benötigte UV an und prüfen sie auch in der Antwort.

6. Synchronisierte und gerätegebundene Passkeys schützen unterschiedliche Stellen

Manche Passkeys synchronisieren zwischen Geräten, andere sind an einen bestimmten Authenticator gebunden. Beide authentifizieren, ohne den privaten Schlüssel an den Anmeldedienst zu übergeben, unterscheiden sich aber in Speicherung, Replikation und Wiederherstellung des Schlüssels.¹⁰

flowchart TB
        accTitle: Synchronisieren und Anmelden sind verschiedene Wege
        accDescr: Ein synchronisierter Passkey repliziert den Schlüssel über einen verschlüsselten Tresor, aber synchronisierte und gerätegebundene Passkeys senden dem Dienst eine Authentifizierungsantwort.
        V["Verschlüsselter Sync-Tresor"] <-->|"Sync und Wiederherstellung"| A["Synchronisierter Passkey auf Gerät A"]
        V <-->|"Sync und Wiederherstellung"| B["Derselbe Passkey auf Gerät B"]
        A -->|"Signierte Antwort"| S["Der Dienst, bei dem angemeldet wird"]
        B -->|"Signierte Antwort"| S
        K["Gerätegebundener Authenticator"] -->|"Signierte Antwort"| S

Abbildung 8: Den Sync-Weg, der den privaten Schlüssel repliziert, vom Anmeldeweg zum Dienst zu trennen, macht den Unterschied klar.

Die Implementierungen von Apple und Google schützen synchronisierte Passkeys mit Ende-zu-Ende-Verschlüsselung. Es ist kein Entwurf, bei dem der Anbieter die in der Cloud gespeicherten Daten unverändert lesen und den privaten Schlüssel erhalten kann.¹¹¹²

Andererseits kann die Wiederherstellung auf einem neuen Gerät zusätzlich zur Anmeldung am Sync-Konto etwa die Bildschirmsperre des vorherigen Geräts oder die PIN des Tresors verlangen. Die genauen Bedingungen unterscheiden sich nach Produkt und Konfiguration. Weder „allein das Cloud-Kontopasswort stellt jeden Passkey wieder her“ noch „wer das Cloud-Konto zurückhat, stellt sie immer wieder her“ trifft zu.¹¹¹³

Bei synchronisierten Passkeys kann sich die Wirkung über mehrere Dienste ausweiten, wenn Entsperr- und Wiederherstellungsmittel des Tresors und die teilnehmenden Geräte ebenfalls kompromittiert sind. Mehr-Faktor-Authentifizierung am Sync-Konto, eine starke Gerätesperre und die Verwaltung der Wiederherstellungsziele zählen. Wo der Dienst es unterstützt, erwägen Sie auch den Schutz mit einem physischen Sicherheitsschlüssel. Liegt der Wiederherstellungsschlüssel nur auf demselben Gerät oder im selben Tresor, haben Sie eine Anordnung gebaut, in der alles auf einmal verloren geht.

Die Zusicherungsstufen in einer Organisation brauchen ebenfalls Aufmerksamkeit. Nach NIST SP 800-63B-4 darf ein synchronisierbarer Authenticator bei AAL2 unter den Bedingungen genutzt werden, bei AAL3, das den Export des privaten Schlüssels nicht erlaubt, jedoch nicht. Umgekehrt erreicht ein gerätegebundener Passkey AAL3 nicht automatisch; die übrigen Anforderungen wie Hardwareschutz müssen ebenfalls erfüllt sein.¹⁴¹⁵

Das Telefon über einen QR-Code zu nutzen ist nicht dasselbe wie Synchronisieren

Es gibt auch ein Verfahren, bei dem Sie einen auf dem PC gezeigten QR-Code mit dem Telefon scannen und sich mit dem Passkey auf diesem Telefon anmelden. Die geräteübergreifende Authentifizierung von FIDO bestätigt die Nähe über Bluetooth oder Ähnliches und führt die Authentifizierung auf dem Telefon aus. Das ist kein Vorgang, der den privaten Schlüssel des Telefons auf den PC kopiert.¹⁶¹

flowchart TB
        accTitle: Anmeldung an einem anderen PC mit dem Schlüssel auf dem Telefon
        accDescr: Das Telefon scannt den QR-Code auf dem PC, und die Authentifizierung läuft über eine Näherungsprüfung und Nutzerverifikation auf dem Telefon. Es ist kein Ablauf, der den privaten Schlüssel auf den PC kopiert.
        A["PC-Anmeldebildschirm zeigt einen QR-Code"] --> B["QR-Code mit dem Telefon scannen"]
        B --> C["Nähe zwischen den Geräten bestätigen"]
        C --> D["Nutzerverifikation und Signatur auf dem Telefon"]
        D --> E["Dienst prüft die Authentifizierungsantwort"]
        E --> F["Anmeldung auf dem PC abgeschlossen"]

Abbildung 9: Die geräteübergreifende Authentifizierung nutzt das Telefon in der Hand als Authenticator und repliziert den Schlüssel nicht auf den PC.

Es kann auch von einem PC funktionieren, der nicht dasselbe Sync-Ziel teilt, ist aber keine Sicherung gegen den Verlust des Telefons, das den Schlüssel speichert. Halten Sie „ich konnte mich vom PC anmelden“ und „auf dem PC ist ebenfalls ein unabhängiger Passkey registriert“ auseinander.

7. Bei Telefonverlust Gerät, Anmeldeinformation und Sitzung getrennt anhalten

Ist ein Gerät verloren, richten Sie von einem sicheren Gerät aus eine Fernsperre und Ähnliches ein und wenden Sie sich bei Verdacht auf Missbrauch umgehend an den Support des Dienstes oder der Organisation. Parallel prüfen Sie, ob Sie mit einem Ersatz-Passkey oder einem Wiederherstellungsverfahren ins Konto kommen. Sie müssen nicht warten, bis die Wiederherstellung abgeschlossen ist, bevor Sie den Verlust melden oder die Nutzung aussetzen. Schutz des Geräts, Schutz des Sync-Kontos und Widerruf auf der Dienstseite haben unterschiedliche Rollen.¹⁷¹⁸

flowchart TB
        accTitle: Was bei Geräteverlust getrennt zu prüfen ist
        accDescr: Während das verlorene Gerät gesichert und der Support kontaktiert wird, ein sicheres Wiederherstellungsverfahren prüfen. Widerruf des Passkeys und Beenden bestehender Sitzungen erfolgen getrennt.
        A["Das Gerät ist verloren"] --> B["Fernsperre und Kontakt zum Support"]
        A --> C["Ersatzschlüssel und Wiederherstellungsverfahren prüfen"]
        B --> D["Nutzung des gefährdeten Passkeys aussetzen"]
        C --> E["Von einem sicheren Gerät aus den Verwaltungsbildschirm öffnen"]
        D --> F["Bestehende Sitzungen getrennt beenden"]
        E --> F
        F --> G["Sync-Ziele und registrierte Authentifizierungsmethoden prüfen"]
        G --> H["In einer sicheren Umgebung neuen Schlüssel und Ersatz einrichten"]

Abbildung 10: Das Gerät anhalten, den Passkey widerrufen und den angemeldeten Zustand beenden sind drei getrennte Handlungen.

Bei einem gerätegebundenen Passkey können Sie die Schritte trennen: die Anmeldeinformation des verlorenen Authenticators auf der Dienstseite widerrufen und eine separat registrierte Ersatzanmeldung nutzen. Bei einem synchronisierten Passkey sind die Kopien auf mehreren Geräten für den Dienst ein und dieselbe Anmeldeinformation, daher stoppt das Löschen dieser Anmeldeinformation auf der Dienstseite auch die Anmeldung der Kopien auf Ihren anderen Geräten bei demselben Dienst. Darauf zu zählen, die Kopie auf einem einzelnen Gerät von der Dienstseite aus einzeln widerrufen zu können, ist nicht zulässig.¹⁰²

Ein Remote Wipe wirkt außerdem nicht unbedingt sofort, wenn das Gerät offline ist. Bei Apples „Wo ist?“ beginnt das Löschen eines Offline-Geräts beim nächsten Onlinegang.¹⁹ Es ist gefährlich zu schließen, das bloße Entfernen eines Geräts aus dem Sync-Konto habe die Kopie des privaten Schlüssels auf diesem Gerät zuverlässig unbrauchbar gemacht. Besteht Sorge vor Missbrauch, müssen Sie die betreffende Anmeldeinformation bei jedem Dienst zügig aussetzen oder widerrufen. Können Sie sich nicht anmelden, nutzen Sie den offiziellen Supportkanal und arbeiten Sie parallel das Verfahren ab, mit dem die berechtigte Person zurückkommt.

Außerdem beendet das Löschen eines Passkeys nicht unbedingt jede bestehende Sitzung. Prüfen Sie gesondert eine Funktion wie „von allen Geräten abmelden“ des Dienstes und auch, ob kein verdächtiger Passkey oder kein verdächtiges Wiederherstellungsziel hinzugefügt wurde.²⁰¹⁸

Bevor ein Gerät verloren geht, lohnt es sich zu klären, ob Ihre wichtigen Dienste die Registrierung mehrerer Passkeys unterstützen, einen unabhängigen Ersatz zu registrieren und sich tatsächlich damit anzumelden. Denselben Schlüssel durch Synchronisierung auf zwei Geräten zu haben, ist bequem, aber nicht dasselbe wie einen zweiten, getrennten Schlüssel registriert zu haben. Bevor Sie Ihr letztes Anmeldemittel löschen, bestätigen Sie die Rückwege einschließlich des Aufbewahrungsorts der Wiederherstellungscodes.

8. Wo auch mit Passkeys Schwachstellen bleiben

Passkeys härten einen wichtigen Teil der Authentifizierung, aber der normale Anmeldebildschirm ist nicht der einzige Weg ins Konto. Bei der Einführung prüfen Sie zusätzlich zur Frage, ob mehr Personen Passkeys nutzen, die folgenden Wege.

flowchart TB
        accTitle: Angriffswege, die nach der Passkey-Einführung bleiben
        accDescr: Neben der Passkey-Anmeldung bleiben schwache Ersatzverfahren, das Wiederherstellungsverfahren, Gerät und Tresor sowie bestehende Sitzungen Ziele.
        B["Schwache alternative Anmeldung"] --> A["Unbefugter Zugriff auf das Konto"]
        C["Missbrauch des Wiederherstellungsverfahrens"] --> A
        D["Kompromittierung von Gerät oder Tresor"] --> A
        E["Missbrauch der Sitzung"] --> A

Abbildung 11: Auch wenn die normale Passkey-Anmeldung stark ist, müssen die anderen Eingänge und der Zustand nach der Anmeldung einzeln geschützt werden.

Alternative Anmeldung. Lassen sich dieselben Vorgänge allein mit Passwort oder SMS ausführen, zielen Angreifende dorthin. Alles auf einmal zu deaktivieren, bevor Ersatz und Wiederherstellung geprüft sind, sperrt jedoch auch berechtigte Personen aus. Schaffen Sie unterstützte Geräte, Ersatzschlüssel und Supportverfahren, dann engen Sie den Umfang ein und reduzieren die Alternativen stufenweise.⁵

Kontowiederherstellung und Schlüsselregistrierung. Die Identitätsprüfung allein auf die Behauptung „mein Gerät ist kaputt“ zu lockern, wird zum Weg, den eigenen Passkey der angreifenden Partei zu registrieren. Bei wichtigen Konten kombinieren Sie Prüfung des Wiederherstellungsantrags, erneute Authentifizierung beim Hinzufügen oder Entfernen einer Authentifizierungsmethode, Änderungsbenachrichtigungen und Prüfung. Eine Benachrichtigung allein verhindert keine unbefugte Registrierung, daher muss die Prüfung vor der Registrierung erfolgen.¹⁸

Gerät und Sync-Tresor. Betriebssystem und Browser aktuell zu halten, das Gerät zu sperren und zu wissen, welche Geräte am Tresor teilnehmen, bleibt nötig. Ein Passkey ist keine Funktion, die aus einem unsicheren PC einen sicheren macht. Auf gemeinsam genutzten Geräten prüfen Sie außerdem, wem die Konfiguration die Nutzung der Anmeldeinformation erlaubt.

Sitzungen. Kann ein gewöhnliches Sitzungscookie gestohlen und genutzt werden, kann eine angreifende Partei manchmal ohne neue Passkey-Authentifizierung arbeiten. Entwerfen Sie Secure, HttpOnly, ein angemessenes SameSite, Lebensdauern, erneute Authentifizierung und serverseitigen Widerruf gesondert. HttpOnly beschränkt das Lesen des Cookies durch JavaScript, verhindert aber nicht, dass XSS eine angemeldete Sitzung missbraucht.²⁰

9. Wichtige Punkte bei der Einführung von Passkeys im eigenen Webdienst

Den API-Aufruf zu tätigen ist nicht die gesamte Anmeldeimplementierung

Die Registrierungs-API von WebAuthn ist navigator.credentials.create(), die Authentifizierungs-API navigator.credentials.get(). FIDO2 besteht aus WebAuthn und CTAP, und CTAP ist die Spezifikation dafür, wie ein Client mit einem Authenticator wie einem externen Sicherheitsschlüssel spricht. Wer einen Webdienst implementiert, muss die USB- oder Bluetooth-Kommunikation nicht selbst bauen.²¹

flowchart TB
        accTitle: Arbeitsteilung bei der Passkey-Implementierung in einem Webdienst
        accDescr: Der Server stellt Anforderungen aus und prüft Antworten, der Browser stellt die API bereit, der Authenticator nutzt den Schlüssel.
        S["Server - stellt Anforderungen aus und prüft Antworten"] <-->|"Anforderungen und Antworten"| B["Browser - die WebAuthn-API"]
        B <--> O["Zusammenarbeit mit OS und Anmeldeinformations-Managern"]
        B <-->|"CTAP und Ähnliches"| A["Externer Authenticator"]

Abbildung 12: Implementieren Sie den Aufruf im Browser zusammen mit Prüfung und Kontoverwaltung auf dem Server.

Als Nächstes das Skelett auf der Browserseite, das zeigt, wohin die an die API übergebenen Werte gehören. Dieses Fragment allein schließt Registrierung oder Anmeldung nicht ab. registrationOptions und authenticationOptions sind Werte, die der Server für diesen Versuch gebaut hat, und Binärposten wie challenge, user.id und die Credential-ID gelten als bereits in die passenden Bytefolgen umgewandelt, nicht als Base64URL-Zeichenfolgen aus dem JSON.²

// Vom Registrieren-Button aufrufen. Der Server stellt die Optionen aus und speichert sie.
async function createPasskey(registrationOptions) {
  if (!window.isSecureContext || !window.PublicKeyCredential) {
    throw new Error("In dieser Umgebung sind Passkeys nicht verfügbar.");
  }
  const credential = await navigator.credentials.create({
    publicKey: registrationOptions,
  });
  if (!credential) throw new Error("Die Passkey-Registrierung wurde nicht abgeschlossen.");
  return credential;
  // Die aufrufende Seite serialisiert die Registrierungsantwort und sendet sie an den Server.
  // Melden Sie die Registrierung erst als abgeschlossen, wenn die Prüfung des Servers gelingt.
}

// Der normale Authentifizierungsablauf, aufgerufen vom Anmelden-Button.
async function usePasskey(authenticationOptions) {
  if (!window.isSecureContext || !window.PublicKeyCredential) {
    throw new Error("In dieser Umgebung sind Passkeys nicht verfügbar.");
  }
  const assertion = await navigator.credentials.get({
    publicKey: authenticationOptions,
  });
  if (!assertion) throw new Error("Die Passkey-Authentifizierung wurde nicht abgeschlossen.");
  return assertion;
  // Die aufrufende Seite serialisiert die Authentifizierungsantwort und sendet sie an den Server.
  // Der Server prüft sie und erzeugt nur bei Erfolg eine Sitzung.
}

In einer echten Oberfläche behandeln Sie das abgelehnte Promise auf der aufrufenden Seite und erläutern Abbruch, Zeitüberschreitung, nicht unterstützte Umgebungen und Ähnliches. Für die Binärumwandlung der Registrierungsantwort und für die Netzaufrufe verringert die Nutzung der entsprechenden APIs der gewählten Bibliothek die Chance, etwas zu übersehen.

In den Registrierungsoptionen ist authenticatorSelection.residentKey: "required" die Einstellung, die eine auffindbare Anmeldeinformation anfordert, mit der ein Konto gewählt werden kann. In einem Entwurf, der die Bestätigung per Biometrie oder PIN zwingend macht, geben Sie bei der Registrierung authenticatorSelection.userVerification: "required" und bei der Authentifizierung userVerification: "required" an. Machen Sie user.id zu einem undurchsichtigen Identifikator von höchstens 64 Byte, den der Server ausstellt, verwenden Sie nicht die E-Mail-Adresse selbst und halten Sie ihn vom Anzeigenamen getrennt.⁷

Wenn Sie Conditional UI nutzen, das den Passkey als Autofill-Vorschlag im Anmeldefeld anbietet, prüfen Sie die Unterstützung mit PublicKeyCredential.isConditionalMediationAvailable() und kombinieren Sie mediation: "conditional" mit autocomplete="username webauthn" am Eingabefeld. Für Umgebungen ohne Unterstützung behalten Sie den normalen, vom Button ausgelösten Ablauf oben.²²

Entwerfen Sie, was der Server prüft, bevor Sie es schreiben

Für die kryptographische Prüfung können Sie Bibliotheken wie SimpleWebAuthn unter Node.js oder fido2-net-lib unter .NET nutzen. Eine Bibliothek zu haben macht Bindung an Konten und Wiederherstellungsentwurf jedoch nicht automatisch sicher.²³²⁴

Diese Tabelle ist ein Satz von Prüfpunkten für die Implementierung, kein Ersatz für die Prüfverfahren der Spezifikation. Nutzen Sie iframes oder Related Origins, prüfen Sie auch die zusätzlichen Bedingungen. Bei gewöhnlicher expliziter Authentifizierung prüfen Sie UP, und wenn Sie UV zwingend gemacht haben, UV auch in der Antwort.⁷⁸

flowchart TB
        accTitle: Die Authentifizierungsentscheidung auf dem Server
        accDescr: Eine Sitzung wird nur ausgestellt, nachdem die Entsprechung zur aktuellen Anforderung, die Nutzungsstelle, die Inhaberschaft der Anmeldeinformation sowie Signatur und Richtlinie geprüft sind.
        A["Authentifizierungsantwort empfangen"] --> B{"Passt sie zu dieser ungenutzten Anforderung"}
        B -->|"Ja"| C{"Sind Site und besitzendes Konto korrekt"}
        C -->|"Ja"| D{"Sind Signatur und die erforderlichen Ergebnisse korrekt"}
        D -->|"Ja"| E["Die Anforderung einmal verbrauchen und eine Sitzung ausstellen"]
        B -->|"Nein"| X["Die Authentifizierung ablehnen"]
        C -->|"Nein"| X
        D -->|"Nein"| X

Abbildung 13: Bestätigen Sie beides: dass die Signatur gültig ist und dass diese Anforderung die Anmeldung bei diesem Konto erlauben soll.

signCount ist auch kein Allzweck-Klonerkenner. Manche Authenticators haben keinen Zähler und geben 0 zurück, und es gibt andere Gründe als Duplizierung, warum ein Wert nicht monoton steigt. Prüfen Sie, wie die unterstützten Umgebungen einschließlich synchronisierter Passkeys und Ihre Bibliothek ihn behandeln, und nutzen Sie abweichende Werte als Eingabe für eine Risikoentscheidung. Vermeiden Sie pauschale Urteile wie „kleiner gleich dem vorherigen Wert bedeutet immer einen Klon“ oder „0 bedeutet, es ist sicher“.⁸

In einer Testumgebung prüfen Sie die Anforderung eines sicheren Kontexts und die RP-ID-Anforderung von WebAuthn getrennt. HTTPS ist in der Regel nötig, und http://localhost kann für die Entwicklung genutzt werden. Dass http://127.0.0.1 als potenziell vertrauenswürdiger Origin gilt, ist etwas anderes als die Frage, ob eine IP-Adresse eine RP-ID sein kann. Weil eine WebAuthn-RP-ID Domänennamenbedingungen erfüllen muss, testen Sie in der Entwicklung mit einer Konfiguration, die Ihr Browser akzeptiert, etwa localhost. Dort erzeugte Anmeldeinformationen lassen sich nicht einfach auf die Produktionsdomäne übertragen.⁹²⁵

10. Was unter Windows und in internen Systemen zu prüfen ist

Unter Windows ist das Wichtige, nicht allein aus „die Windows-Hello-Abfrage erschien“ zu schließen, wo ein Passkey gespeichert ist oder ob er synchronisiert. Nutzerverifikation durch Windows Hello und Speicherung sowie Synchronisierung mit einem Anmeldeinformations-Manager von Microsoft oder einem anderen Anbieter sind getrennte Prüfpunkte. Manche Passkeys liegen lokal, andere bei einem Sync-Anbieter.²⁶

flowchart TB
        accTitle: Reihenfolge der Prüfungen bei der Passkey-Einführung unter Windows
        accDescr: Anmeldeziel, Speicherort der Anmeldeinformation, Erlaubnisrichtlinie der Organisation und Wiederherstellung nach Verlust getrennt und in dieser Reihenfolge prüfen.
        A["Wobei melden Sie sich an"] --> B["Webdienste, Entra ID und Windows unterscheiden"]
        B --> C["Prüfen, wo der Passkey gespeichert ist und ob er synchronisiert"]
        C --> D["Richtlinie der Authentifizierungsmethoden und Authentifizierungsstärke prüfen"]
        D --> E["Ersatzschlüssel und das Verfahren bei Verlust testen"]

Abbildung 14: Dieselbe Windows-Hello-Abfrage kann je nach Anmeldeziel und Speicherort betrieblich Unterschiedliches bedeuten.

Anmeldeinformationen im lokalen Windows-Hello-Container sind nicht dasselbe wie ein synchronisierter Tresor. In einer Windows-Hello-Konfiguration, die das TPM nutzt, spielt der TPM-Schutz des Schlüssels eine wichtige Rolle. Gleichsetzen Sie trotzdem die allgemeine Einordnung von Passkeys nicht mit dem Vorhandensein eines TPM; urteilen Sie nach tatsächlichem Speicherort, Gerät und Anforderungen der Organisation.²⁷²⁸

In Microsoft Entra ID entwerfen Sie die Richtlinie der Authentifizierungsmethoden, die die Passkey-Nutzung erlaubt, getrennt von der Authentifizierungsstärke in Conditional Access, die entscheidet, wie stark eine Authentifizierung eine gegebene Ressource verlangt. Allein die Möglichkeit, einen Passkey zu registrieren, beschränkt nicht automatisch allen Zugriff auf phishing-resistente MFA. Welche Passkey-Arten Sie erlauben, einschließlich synchronisierter, sollten Sie gegen den aktuellen Unterstützungsstand und die Richtlinie der Organisation festlegen.²⁹

Machen Sie eine interne Webanwendung selbst zum WebAuthn-RP, schaffen Sie zuerst HTTPS, Zertifikate, Namensauflösung und einen Domänennamen, der als stabile RP-ID dient. Übergeben Sie die Arbeit an eine Identitätsplattform, entwirft die Anwendungsseite die Integration mit dieser Plattform und deren Sitzungsverwaltung. Entra ID aus einer WinForms- oder WPF-Anwendung zu nutzen und dass die Anwendung selbst zur WebAuthn-Relying-Party wird, ist ebenfalls nicht dasselbe.

Passkeys sind auch keine Funktion, die die Authentifizierung gegenüber SMB-Freigaben automatisch ersetzt oder NTLM- oder Kerberos-Probleme direkt behebt. Zu entscheiden, welche Anmeldung Sie ändern, und Registrierung, Authentifizierung, Verlust und Wiederherstellung zuerst an einem kleinen Ziel zu erproben, führt zu einer Einführung, die den Betrieb nicht anhält.

11. Zusammenfassung — das Geheimnis nicht zu übergeben und alles darum zu schützen gehören zusammen

Die Stärke eines Passkeys liegt darin, mit einer Signatur zu authentifizieren, die an die aktuelle Anforderung und an die Nutzungsstelle gebunden ist, ohne den privaten Schlüssel an den Anmeldedienst zu übergeben. Allein der Abfluss des öffentlichen Schlüssels erlaubt keine gültige Signatur, und die Anmeldeinformation für die echte Site lässt sich von einer nicht zugehörigen gefälschten Site nicht nutzen.

Zugleich müssen der synchronisierte Tresor, die Gerätesperre, alternative Anmeldungen, das Wiederherstellungsverfahren und die Sitzung nach der Anmeldung geschützt bleiben. Die Maßnahmen, die der Wechsel zu Passkeys überflüssig macht, von denen zu trennen, die weiterhin nötig sind, ist die Perspektive, mit der Sie eine Einführung richtig bewerten.

Als nutzende Person prüfen Sie, wo Ihre Passkeys gespeichert sind und welche Wiederherstellungsmittel Sie haben, und richten Sie für wichtige Konten einen unabhängigen Ersatz ein. Als Implementierende entwerfen Sie die serverseitige Prüfung, die Verwaltung mehrerer Passkeys sowie Widerruf und Wiederherstellung als eine Funktion. So weit zu gehen, trägt Bequemlichkeit und Phishing-Resistenz in den tatsächlichen Betrieb.

Verwandte Artikel

• Was ist das TPM unter Windows? — Anhand von Diagrammen: der Tresor, der Schlüssel nicht nach außen gibt, und Measured Boot
• NTLM und Kerberos anhand von Diagrammen — warum die Authentifizierung auf NTLM „fällt“
• Entra-ID-Authentifizierung in WinForms/WPF-Anwendungen einbinden — praxisnahe Architektur mit MSAL.NET und dem WAM-Broker
• Anmeldeinformationen in PowerShell sicher behandeln — Klartextpasswörter aus Skripten verbannen
• Mindest-Sicherheitscheckliste für die Windows-Anwendungsentwicklung
• Womit KMU bei der Sicherheit beginnen sollten — ein Rundgang durch die IPA-„Richtlinie zur Informationssicherheit für KMU“, 4. Auflage

Verwandte Beratungsleistungen

Komura Soft LLC übernimmt Custom Software Development, darunter die Überprüfung der Authentifizierungsfunktionen interner Websysteme, die Anbindung an Entra ID und den Einbau der Authentifizierung in Windows-Fachanwendungen wie WinForms und WPF. Auch bei der Prüfung einer Passkey-Unterstützung ordnen wir nicht nur den Anmeldebildschirm, sondern die genutzten Geräte, die bestehende Authentifizierungsplattform und die Wiederherstellungsverfahren gemeinsam.

Referenzlinks

Spezifikationen und Produktinformationen sind zum Stand 8. September 2026 geprüft. Welche Funktionen verfügbar sind, unterscheidet sich nach Browser, Betriebssystem und Tenant-Einstellungen.

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.

Warum sind Passkeys sicherer als Passwörter?

Weil sie mit einer Signatur authentifizieren, die an die aktuelle Challenge und an die Nutzungsstelle gebunden ist, ohne den privaten Schlüssel je an den Anmeldedienst zu übergeben. Allein der Abfluss des öffentlichen Schlüssels erlaubt keine gültige Signatur, und ein Passkey für die echte Site lässt sich von einer nicht zugehörigen gefälschten Site nicht nutzen. Trotzdem muss der Server die Prüfung korrekt durchführen, und Gerät, Wiederherstellungsverfahren und Sitzung müssen geschützt bleiben.

Werden Fingerabdruck- oder Gesichtsdaten an die Site gesendet?

Eine WebAuthn-Authentifizierungsantwort trägt weder ein Fingerabdruckbild noch einen Gesichtsmerkmalvektor zum Anmeldedienst. Biometrie und PIN dienen auf der Nutzerseite dazu, die Verwendung des privaten Schlüssels zu erlauben; der Dienst prüft die Signatur und das Ergebnis der Nutzerverifikation.

Wenn der private Schlüssel nie gesendet wird, wie kann ein Passkey synchronisieren?

Weil die Authentifizierung gegenüber dem Dienst und die Synchronisierung durch den Anmeldeinformations-Manager zwei verschiedene Wege sind. Ein synchronisierter Passkey verschlüsselt den privaten Schlüssel und repliziert ihn zwischen Geräten; das ist nicht dasselbe, wie den privaten Schlüssel an den Anmeldedienst zu übergeben. Die Bedingungen zum Entsperren und Wiederherstellen des Sync-Tresors unterscheiden sich nach Produkt und Konfiguration.

Was geschieht mit Konten, die Passkeys nutzen, wenn ich mein Telefon verliere?

Bei einem synchronisierten Passkey können Sie ihn auf einem anderen Gerät nutzen, sobald die Wiederherstellungsbedingungen des Tresors erfüllt sind; bei einem gerätegebundenen Passkey brauchen Sie eine separat registrierte Ersatzanmeldung oder ein Wiederherstellungsverfahren. Während Sie das Gerät sichern und den Verlust melden, prüfen Sie einen sicheren Rückweg und behandeln den Widerruf der gefährdeten Anmeldeinformation und das Beenden bestehender Sitzungen als zwei getrennte Schritte. Widerruft der Dienst dieselbe synchronisierte Anmeldeinformation, können die Kopien auf Ihren anderen Geräten sich bei diesem Dienst ebenfalls nicht mehr anmelden.

Machen Passkeys Maßnahmen gegen Phishing überflüssig?

Nein. Passkeys sind stark gegen die Übergabe von Anmeldeinformationen an eine gefälschte Domäne, aber die Verleitung zum Wechsel auf Passwort oder SMS, der Missbrauch des Wiederherstellungsverfahrens und die Kompromittierung von Gerät oder Sitzung brauchen jeweils eigene Gegenmaßnahmen.

Ist ein mit Windows Hello genutzter Passkey immer gerätegebunden?

Allein die Windows-Hello-Abfrage sagt weder, wo die Anmeldeinformation gespeichert ist, noch ob sie synchronisiert. Unterscheiden Sie Anmeldeinformationen im lokalen Container von Passkeys bei einem Sync-Anbieter und prüfen Sie den tatsächlichen Speicherort, das Gerät und die Richtlinie der Organisation.

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.