Überblick
Konventionelle Passwort-plus-OTP- oder Push-MFA reduziert das Risiko eines gestohlenen Passworts. Manuell eingegebene Codes und Freigabeaufforderungen sind jedoch nicht automatisch an den legitimen Dienst gebunden. Angreifer können OTPs über Adversary-in-the-Middle-Phishing weiterleiten, Benutzer mit wiederholten Push-Anfragen unter Druck setzen oder nach der Authentifizierung eine Bearer-Sitzung stehlen.
Gerätegebundene Authentifizierung verändert das Credential selbst. Ein gerätegebundener Passkey hält seinen privaten Schlüssel in einem bestimmten Authenticator wie Security Key, TPM oder Secure Enclave und erlaubt weder Export noch Synchronisierung. WebAuthn bindet jede Assertion außerdem an die Relying Party und eine frische Challenge; dadurch wird die Authentifizierungszeremonie phishing- und replayresistent.
Diese Eigenschaften verhindern Credential-Phishing und das Kopieren des privaten Authentifizierungsschlüssels. Sie machen jedoch nicht automatisch jede Anwendungssitzung gerätegebunden. Viele Anwendungen verwenden weiterhin Bearer-Cookies, die bei Diebstahl wiederverwendbar sein können. Dafür sind kurze Laufzeiten, risikobasierte Reauthentifizierung, Proof-of-Possession oder gerätegebundene Sitzungs-Credentials erforderlich.
Gerätebindung ist ebenfalls nicht dasselbe wie Vertrauen in ein verwaltetes Gerät. Ein nicht exportierbares Credential kann auf einem unverwalteten Privatgerät liegen. Attestierung kann bei Registrierung Hinweise auf Herkunft und Eigenschaften des Authenticators liefern; aktueller Patchstand, Verschlüsselung oder Agent-Zustand kommen aus separaten Management- und Posture-Signalen.
Fünf Kontrollen beantworten unterschiedliche Fragen
- Benutzerpräsenz. Hat eine Person eine Autorisierungsgeste ausgeführt, etwa einen Security Key berührt?
- Benutzerverifizierung. Hat der Authenticator den Benutzer lokal per Biometrie, PIN oder gleichwertigem Verfahren verifiziert?
- Credential-Bindung. Ist der private Authentifizierungsschlüssel nicht exportierbar und auf einen bestimmten Authenticator beschränkt?
- Vertrauen in verwaltete Geräte. Erkennt, verwaltet und vertraut die Organisation dem Endpoint, der das Credential verwendet?
- Sitzungsbindung. Muss der Client nach der Authentifizierung weiter den Besitz eines kryptografischen Schlüssels nachweisen, oder genügt ein Bearer-Cookie?
Vergleich der Kontrollen
| Kontrolle | Was sie nachweist | Phishingresistent | Stoppt Wiederverwendung einer gestohlenen Bearer-Sitzung |
|---|---|---|---|
| Passwort plus OTP | Kenntnis eines Passworts und Zugriff auf eine OTP-Quelle | Nein | Nein |
| Passwort plus Push | Kenntnis eines Passworts und Freigabemöglichkeit auf einem registrierten Authenticator | Nicht zwingend | Nein |
| Synchronisierter Passkey | Besitz eines über den Provider verfügbaren Passkeys plus lokale Autorisierung | Ja | Nein |
| Gerätegebundener Passkey | Besitz eines nicht exportierbaren Credential-Schlüssels in einem bestimmten Authenticator | Ja | Nein |
| Conditional Access für verwaltete Geräte | Der Endpoint erfüllt Registrierungs- und Posture-Richtlinien der Organisation | Abhängig von der Authentifizierungsmethode | Nein |
| Gerätegebundene Sitzung | Fortlaufender Besitz eines sitzungsspezifischen kryptografischen Schlüssels | Keine Authentifizierungsmethode | Reduziert Replay-Risiko bei korrekter Implementierung |
Abgedeckte Angriffe
- Credential-Phishing und Relay. WebAuthn nutzt Verifier-Name-Binding, sodass eine gefälschte Website keine für die legitime Relying Party gültige Assertion erhält.
- Prompt Fatigue. Passkey-Authentifizierung entfernt das wiederverwendbare Push-Freigabemuster, das Angreifer wiederholt auslösen können.
- Replay der Authentifizierung. Eine frische Server-Challenge macht eine aufgezeichnete WebAuthn-Assertion für eine spätere Zeremonie unbrauchbar.
- Diebstahl von Sitzungstokens. Dies ist ein separates Risiko nach der Authentifizierung. Gerätegebundene Credentials verwandeln ein normales Bearer-Cookie nicht in eine gerätegebundene Sitzung.
- Zugriff von unverwalteten Geräten. Setzen Sie dies über Geräteregistrierung und Conditional-Access-Richtlinien durch; Credential-Bindung allein beweist nicht, dass IT den Endpoint verwaltet.
Was zu bewerten ist
- Erforderliches Assurance-Niveau. Bestimmen Sie, welche Rollen gerätegebundene Passkeys benötigen und wo unternehmenskontrolliert synchronisierte Passkeys genügen.
- Attestierungsrichtlinie. Dokumentieren Sie, ob Attestierung angefordert wird, welche Trust Roots und Modelle akzeptiert werden, wie Datenschutz geschützt wird und was bei fehlender Attestierung geschieht.
- Erkennung verwalteter Geräte. Definieren Sie, wie MDM-Registrierung, Gerätezertifikate, Plattformattestierung oder andere Mechanismen genehmigte Endpoints identifizieren.
- Aktualität des Gerätestatus. Legen Sie Signale und deren zulässiges Alter fest sowie die Reaktion auf fehlende oder veraltete Daten: Ablehnung, Step-up oder eingeschränkte Sitzung.
- Sitzungsschutz. Bewerten Sie Cookie-Laufzeit, Token-Speicherung, Reauthentifizierung, Anomalieerkennung, Widerruf und Proof-of-Possession beziehungsweise gerätegebundene Sitzungen.
- Wiederherstellung und Ersatz. Halten Sie Recovery bei Geräteverlust phishingresistent und definieren Sie Widerruf, Ersatz und Audit-Nachweise.
- Ausnahmen. Entwerfen Sie kontrollierte Pfade für BYOD, Auftragnehmer, gemeinsam genutzte Geräte, Break-Glass-Zugriff und Plattformen ohne unterstützten Hardwareschutz.
So nutzen Sie diese Ressource
Stimmen Sie Security, IT und Einkauf darüber ab, welchen Schutz konventionelle MFA, gerätegebundene Credentials, Gerätestatus und Sitzungsbindung jeweils bieten. Übersetzen Sie die Unterschiede in messbare POC-Akzeptanzkriterien.