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. Der Punkt hier: Passkey-Rollout als Identity-Projekt behandeln, nicht als neuen Button auf der Login-Seite.

Technisch ist eine Passkey ein WebAuthn-Schluesselpaar (meist ES256 oder EdDSA), gebunden an eine Origin. Der private Schluessel lebt in einem Authenticator: Secure Enclave auf iPhone, TPM 2.0 in Windows Hello, StrongBox auf Android, oder ein externes Token wie YubiKey 5C NFC. Der Server speichert nur den oeffentlichen Schluessel und die credentialId. Klassisches Phishing scheitert, weil die Signatur an die RP ID (Domain) gebunden ist. In Tests gegen evilginx2-Klone verweigert die Passkey schlicht das Signieren fuer die falsche Domain, waehrend TOTP zu 100% hinter einem Reverse Proxy faellt. Praktisches Setup in Web-Pentest von Null: Ein Sicheres Lab mit DVWA, Juice Shop und Burp Suite Bauen und Adversary-Kontext in Autorisiertes Red-Team-Phishing: Templates, GoPhish und Ethische Leitplanken.

Das eigentliche Risiko ist nicht das Protokoll, sondern die Recovery. Kartiere, wie dein Anbieter (Apple iCloud Keychain, Google Password Manager, 1Password, Bitwarden) Credentials syncht und wie die Restore-Zeremonie aussieht. Apple verlangt Geraete-Passcode plus Recovery-Kontakt oder einen 28-Zeichen-Recovery-Key. Google baut auf das Screen-Lock des vorherigen Geraets. Wenn du SMS und E-Mail als Fallback abschaltest, ohne den Pfad zu konfigurieren, ist es vorbei. 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.

Fuer Corporate-Teams ist meine Regel: zwei physische Authenticators pro kritischem Nutzer (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 setz die Attestation Policy auf FIDO2 L1+ zertifizierte Authenticators fuer Privileged Accounts. Schalte Self-Service-Enrollment ohne Review fuer Admin-Gruppen ab. Fuer persoenliche Forscher-Accounts kombiniere synchronisierte Passkey (Komfort) mit physischem Security Key (Resilienz). Das Workstation-Playbook in Windows 11 Hardening fuer Hochrisiko Arbeitsplaetze deckt den Endpoint ab, macOS-Hardening: Lockdown Mode, MDM und Angriffsflaechenreduktion das Apple-Aequivalent.

Helpdesk ist, wo 80% der Bypasses passieren. MGM, Caesars und Cloudflare haben dasselbe Muster dokumentiert: Angreifer ruft an, faked Geraeteverlust, Helpdesk resettet MFA. Mit Passkey verschiebt sich der Vektor, verschwindet aber nicht, er wird zu Passkey-Reset. Erzwinge Out-of-Band-Verifizierung: Video-Call mit Ausweis oder Manager-Freigabe ueber separaten Kanal. Logge jede Reset-Operation mit 1-Jahres-Retention und SIEM-Alert. Wenn du Sigma faehrst, schreib eine Rule fuer Credential-Reset ausserhalb der Geschaeftszeiten gefolgt von Login aus neuer Geo - konkretes Beispiel in Threat Hunting mit Sigma und Elastic: Vom Indikator zur Detektionsregel und Hunting-Patterns in Hunting von Living-off-the-Land-Binaries unter Windows mit KQL.

Verschwindet das Passwort? 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 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: 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 - perfekter 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.

Praktisches 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.