Passwoerter und MFA: Umstieg auf Passkeys ohne Recovery zu zerstoeren

Als mich ein Kunde das erste Mal um 23 Uhr anrief, weil sein CFO sein iPhone in den Pool geworfen und den Zugang zu allem verloren hatte, wurde klar: eine Passkey ohne Recovery-Plan ist nur eine elegante Art, sich selbst auszusperren. Passkeys loesen das richtige Problem: sie killen Passwort-Reuse, Reverse-Phishing und den groessten Teil der MFA-Fatigue, die heute Incidents ausloest. Aber ein schlampiges Rollout schafft eine ganz neue Incident-Klasse: legitimer Nutzer ausgesperrt, kein vertrauenswuerdiger Reset-Kanal, Helpdesk wird zum Social-Engineering-Vektor. Dieser Beitrag behandelt Passkey-Rollout als Identity-Projekt, nicht als neuen Button auf der Login-Seite, und geht die Kette Protokoll, Recovery, Team-Enrollment, Helpdesk, Detection und Checkliste in der Reihenfolge durch, in der sie im echten Betrieb bricht.

Was eine Passkey technisch wirklich ist

Eine Passkey ist ein WebAuthn/FIDO2-Schluesselpaar, in der Regel ES256 (P-256) oder EdDSA (Ed25519), erzeugt beim Registrieren und fest an eine Origin gebunden. Der private Schluessel verlaesst niemals den Authenticator: Secure Enclave auf dem iPhone, TPM 2.0 hinter Windows Hello, StrongBox auf Android oder ein externes Token wie ein YubiKey 5C NFC. Der Server (die Relying Party) speichert ausschliesslich den oeffentlichen Schluessel, die credentialId und einen Signaturzaehler. Beim Login schickt der Server eine zufaellige Challenge, der Authenticator signiert sie nach einer User-Presence- oder User-Verification-Geste, und der Server prueft die Signatur gegen den hinterlegten Public Key. Es gibt kein geteiltes Geheimnis, das man phishen, in einer Datenbank leaken oder per Reverse-Proxy abgreifen koennte.

Warum Phishing am Protokoll scheitert

Der entscheidende Wert liegt in der Bindung an die RP ID (die eingetragene Domain). Der Browser signiert nur, wenn die aufrufende Origin zur registrierten RP ID passt; die Signatur enthaelt zudem einen clientDataHash ueber Origin und Challenge. In Tests gegen einen evilginx2-Klon verweigert die Passkey schlicht das Signieren fuer die falsche Domain, waehrend TOTP hinter einem Reverse-Proxy zu 100% durchgereicht wird, weil der Nutzer den Code freiwillig in eine Look-alike-Seite tippt. Genau diese Angreifer-Perspektive baust du in einem Labor nach, wie in Autorisiertes Red-Team-Phishing: Templates, GoPhish und Ethische Leitplanken, und den generellen Web-Aufbau in Web-Pentest von Null: Ein Sicheres Lab mit DVWA, Juice Shop und Burp Suite Bauen.

Das eigentliche Risiko: Recovery, nicht das Protokoll

Kartiere, wie dein Anbieter Credentials synchronisiert und wie die Restore-Zeremonie aussieht. Apple iCloud Keychain verlangt Geraete-Passcode plus Recovery-Kontakt oder einen 28-Zeichen-Recovery-Key. Google Password Manager haengt am Screen-Lock des vorherigen Geraets. Password-Manager wie 1Password und Bitwarden syncen die Passkey ueber dein Vault, dessen Master-Secret dann zum eigentlichen Kronjuwel wird. Der Fehler, der Menschen aussperrt: SMS und E-Mail als Fallback abschalten, ohne den neuen Pfad zu konfigurieren. Dokumentiere den Flow in einem persoenlichen Threat Model vor der Migration; OPSEC fuer Security-Researcher: Persoenliches Bedrohungsmodell enthaelt das Geruest, das ich mit Hochrisiko-Kunden und Journalisten nutze.

Synced vs. device-bound: die falsche Debatte

Eine synchronisierte Passkey ist bequem und ueberlebt Geraeteverlust, weil sie in der Cloud des Providers liegt; ihre Sicherheit ist so gut wie das Account-Recovery dieses Providers. Eine device-bound Passkey (Hardware-Token, Platform-Key ohne Sync) verlaesst das Silicon nie und ueberlebt kein verlorenes Geraet ohne zweite Kopie. Die reife Antwort ist kein Entweder-oder: fuer persoenliche Forscher-Accounts kombiniere eine synchronisierte Passkey fuer Komfort mit einem physischen Security Key fuer Resilienz. Verwechsle im Inventar niemals eine synced Passkey mit einer hardware-bound - die Attestation im Registrierungs-Flow sagt dir, was du wirklich hast.

Rollout fuer Teams: zwei Authenticators, harte Policy

Meine Regel fuer kritische Nutzer: zwei physische Authenticators (z.B. YubiKey 5C plus YubiKey 5 Nano), am gleichen Tag enrolled, einer im physischen Safe. In IdPs wie Entra ID, Okta oder Google Workspace setzt du die Attestation-Policy auf FIDO2 L1+-zertifizierte Authenticators fuer Privileged Accounts und schaltest Self-Service-Enrollment ohne Review fuer Admin-Gruppen ab. Erzwinge User Verification (userVerification: required), nicht nur User Presence. Das Workstation-Playbook in Windows 11 Hardening fuer Hochrisiko Arbeitsplaetze deckt den Endpoint ab, macOS-Hardening: Lockdown Mode, MDM und Angriffsflaechenreduktion das Apple-Aequivalent.

Der Helpdesk-Vektor: wo 80% der Bypasses passieren

MGM, Caesars und Cloudflare haben dasselbe Muster dokumentiert: Angreifer ruft an, faked Geraeteverlust, Helpdesk resettet MFA. Mit Passkey verschwindet der Vektor nicht, er wird zu Passkey-Reset. Erzwinge Out-of-Band-Verifizierung: Video-Call mit Ausweis oder Manager-Freigabe ueber einen separaten, vorab definierten Kanal - niemals ueber denselben Kanal, aus dem die Anfrage kam. Fuege eine Verzoegerung fuer Hochrisiko-Resets ein und benachrichtige den echten Kontoinhaber ueber einen zweiten Draht, bevor der Reset scharf wird. Jede Reset-Operation wird geloggt, mit 1-Jahres-Retention und SIEM-Alert.

Detection: Reset-Anomalien in Sigma

Ein Reset ausserhalb der Geschaeftszeiten, gefolgt von einem Login aus einer neuen Geo innerhalb von Minuten, ist ein Klartext-Signal. Wenn du Sigma faehrst, schreib eine Rule fuer credential/authenticator reset gefolgt von login aus abweichender ASN oder unmoeglichem Reisezeit-Delta. Konkretes Beispiel in Threat Hunting mit Sigma und Elastic: Vom Indikator zur Detektionsregel, ergaenzende Hunting-Patterns fuer die Zeit nach dem Zugang in Hunting von Living-off-the-Land-Binaries unter Windows mit KQL. Alarmiere auf Enrollment eines neuen Authenticators kurz nach einem Reset - das ist die klassische Persistenz-Handlung des Angreifers.

Passwort abschalten? Der phasenweise Weg

Nicht so schnell. In der Praxis behalte ein starkes Passwort (>=20 Zeichen, Manager-generiert) als Backup auf Accounts, die noch kein Passkey-Only unterstuetzen, und schalte SMS wo moeglich ab. Auf Accounts, die es schon koennen (Google, Microsoft, GitHub, Apple, Cloudflare), schalte Passkey-Only erst nach 30 Tagen Parallel-Test scharf. Lagere gedruckte Backup-Codes im Safe, getrennt von den Authenticators. Fuer Disk- und Passwort-Tresor-Krypto zeigt Disk-Krypto und Backups: VeraCrypt, LUKS und eine Belastbare 3-2-1-Strategie, wie man 3-2-1 anwendet, ohne in eine Einzelkopie zu kollabieren, die zum SPOF wird.

Haeufige Fehler aus Audits

Immer wieder dieselben fuenf: 1) Global Admin mit nur einer Passkey auf einem privaten Handy; 2) Recovery-Mail zeigt auf einen Account ohne MFA; 3) BitLocker-Recovery-Key in der Cloud desselben Accounts, den du wiederherstellen willst - der perfekte Loop; 4) Helpdesk darf MFA per Ticket ohne Manager-Freigabe abschalten; 5) synchronisierte Passkey im Inventar als hardware-bound markiert. Pruefe das mit einer vierteljaehrlichen Purple-Team-Uebung, gleicher Loop wie in Purple Team in der Praxis: Aufbau eines Red-Blue-Feedback-Zyklus. In autorisierten Red-Team-Einsaetzen sind das die ersten Pfade, die wir nach Initial Access testen.

Migrations-Checkliste

Pro kritischem Account, in dieser Reihenfolge: (a) zwei Authenticators auf verschiedener Hardware registrieren; (b) Attestation pruefen, ob synced oder device-bound; (c) Backup-Codes drucken und im Safe versiegeln; (d) einen Recovery-Testlauf ohne das Hauptgeraet durchspielen; (e) SMS-Fallback entfernen; (f) Recovery-Mail auf einen ebenfalls MFA-geschuetzten Account zeigen lassen; (g) die Reset-Prozedur dokumentieren und im SIEM alarmieren. Erst wenn alle sieben gruen sind, ist der Account wirklich migriert - nicht schon, wenn der neue Login funktioniert.

Discoverable Credentials und Usernameless Login

Eine resident key (discoverable credential) speichert die User-Handle-Zuordnung im Authenticator selbst, sodass der Login ganz ohne vorher getippten Benutzernamen funktioniert: der Browser bietet ueber die Conditional UI (WebAuthn autofill) direkt die passende Passkey an. Das ist bequem, hat aber eine Kapazitaetsgrenze - aeltere YubiKeys speichern nur etwa 25 resident keys, und ein voller Slot fuehrt zu stillen Enrollment-Fehlern, die im Rollout schwer zu debuggen sind. Auf geteilten oder Kiosk-Geraeten sind discoverable credentials zudem ein Datenschutzrisiko, weil eine Liste der Konten am Geraet sichtbar wird. Entscheiden Sie bewusst zwischen resident (usernameless) und non-resident (server-side credential) je nach Bedrohungsmodell des Geraets, statt den Default zu uebernehmen.

Cross-Device: hybrid transport ueber CTAP 2.2

Der haeufigste Praxisfall - Login am Desktop mit der Passkey vom Handy - laeuft ueber den hybrid transport (frueher caBLE): der Desktop zeigt einen QR-Code, das Handy scannt ihn und bestaetigt ueber eine BLE-Proximity-Pruefung, dass beide Geraete physisch nah sind. Diese Naehe-Anforderung ist genau der Grund, warum sich Passkeys nicht remote phishen lassen wie ein OTP-Code am Telefon. Testen Sie in Ihrem Rollout explizit den Cross-Device-Flow, denn er scheitert oft an deaktiviertem Bluetooth, restriktiven Firmennetzen oder veralteten Authenticator-Apps - und ein Nutzer, der den einzigen Recovery-Pfad nicht ausfuehren kann, ist genauso ausgesperrt wie einer ohne Backup.

FAQ: Sind Passkeys quantensicher?

Nein, ES256 und EdDSA sind klassische elliptische Kurven und gegen einen kryptografisch relevanten Quantencomputer nicht sicher. Das ist praktisch aber nachrangig: Passkeys nutzen Challenge-Response, es wird kein wiederverwendbares Geheimnis ueber die Leitung geschickt, das man aufzeichnen und spaeter brechen koennte. Die FIDO Alliance arbeitet bereits an PQC-Attestation und -Signaturen; migrationsseitig aendert sich fuer dich nichts, wenn die Authenticator-Firmware und der Browser das ausrollen.

FAQ: Was, wenn ich alle Geraete gleichzeitig verliere?

Genau dafuer existiert der versiegelte Umschlag: gedruckte Backup-Codes plus ein dritter, ausschliesslich offline gelagerter Hardware-Key im Safe oder Bankschliessfach loesen das Total-Loss-Szenario. Auf Provider-Ebene ist der Recovery-Kontakt (Apple) oder ein Business-Admin-Reset ueber verifizierte Out-of-Band-Kanaele dein letzter Weg zurueck. Wenn dein einziger Wiederherstellungspfad SMS an eine verlorene SIM ist, hast du kein Recovery, sondern eine Illusion davon.

Fazit und praktischer Takeaway

Am naechsten Freitag oeffnest du deine 5 kritischsten Accounts (Primaer-Mail, Bank, Passwort-Manager, Corporate IdP, Domain-Registrar). Fuer jeden registrierst du 2 Passkeys auf verschiedenen Authenticators, druckst Backup-Codes, validierst, dass du ohne Hauptgeraet einloggen kannst, und entfernst SMS als Fallback. Dokumentiere die Recovery-Prozedur in einem versiegelten Umschlag. Wenn du das nicht in 90 Minuten pro Account schaffst, bist du noch nicht bereit, das Passwort abzuschalten - und das ist ok, es ist Teil des Plans. Passkeys sind ein enormer Sicherheitsgewinn, aber nur, wenn der Recovery-Pfad genauso ernst genommen wird wie der Login selbst.