Passkeys & FIDO2 — das Ende der Passwörter

Kryptographische Grundlagen — warum Passkeys unknackbar sind

Passkeys basieren auf asymmetrischer Kryptographie: Bei der Registrierung generiert das Gerät des Benutzers ein Schlüsselpaar (privater + öffentlicher Schlüssel). Der private Schlüssel verlässt das Gerät niemals — er wird im Secure Enclave (Apple), TPM (Windows), StrongBox/TEE (Android) oder auf einem Hardware-Security-Key (YubiKey) gespeichert. Der öffentliche Schlüssel wird an den Server gesendet und dort gespeichert. Bei der Authentifizierung sendet der Server eine Challenge (zufällige Nonce), das Gerät signiert diese Challenge mit dem privaten Schlüssel, und der Server verifiziert die Signatur mit dem öffentlichen Schlüssel. Das Entscheidende: Es wird kein Geheimnis übertragen — selbst wenn der Server kompromittiert wird, erhält der Angreifer nur öffentliche Schlüssel, die wertlos sind.

Der Phishing-Schutz von Passkeys ist architektonisch eingebaut: Die WebAuthn-Spezifikation bindet jeden Passkey an die Origin (Domain) des Dienstes. Ein Passkey für bank.de funktioniert nur auf bank.de — nicht auf bank-de-login.evil.com. Selbst wenn ein Benutzer auf eine perfekte Phishing-Seite hereinfallen würde, würde sein Browser den Passkey nicht präsentieren, weil die Origin nicht übereinstimmt. Dies eliminiert nicht nur Phishing, sondern auch Adversary-in-the-Middle (AitM) Angriffe wie EvilGinx2, die bei herkömmlicher MFA die Session-Tokens abfangen. Passkeys mit device-bound Credentials (z. B. auf einem YubiKey) erfüllen die höchste NIST AAL3-Sicherheitsstufe.

• Discoverable vs. Non-Discoverable Credentials: Discoverable Credentials („Resident Keys“) speichern den Credential-Identifier auf dem Authenticator — der Benutzer kann sich ohne Benutzernamen anmelden („usernameless login“). Non-Discoverable Credentials erfordern, dass der Server zuerst den Credential-Identifier sendet (der Benutzer muss seinen Benutzernamen eingeben). Passkeys sind standardmäßig Discoverable. Einschränkung: Hardware-Keys (YubiKey 5) haben nur 25 Resident-Key-Slots — danach müssen ältere Credentials überschrieben werden.
• Synced vs. Device-Bound Passkeys: Synced Passkeys werden über Cloud-Dienste synchronisiert (iCloud Keychain, Google Password Manager, 1Password): Vorteil: Geräteverlust führt nicht zum Zugriffsverlust. Nachteil: Die privaten Schlüssel verlassen das Gerät (verschlüsselt in die Cloud). Device-Bound Passkeys (YubiKey, Windows Hello) verlassen das Gerät nie: Höchste Sicherheit, aber Verlust des Authenticators = Zugriffsverlust (Backup-Strategie erforderlich). Für Unternehmen: Device-bound für Administratoren, synced für normale Benutzer.
• Attestation — den Authenticator verifizieren: Bei der Registrierung kann der Server eine Attestation anfordern: Der Authenticator liefert ein vom Hersteller signiertes Zertifikat, das beweist, welches Gerätemodell den Schlüssel generiert hat. Für Enterprises: Nur bestimmte Authenticator-Modelle erlauben (z. B. nur YubiKey 5 FIPS oder nur Windows Hello mit TPM 2.0). FIDO Metadata Service (MDS) enthält die Zertifikate und Sicherheitseigenschaften aller zertifizierten Authenticatoren.
• Cross-Device Authentication (Hybrid Transport): Wenn der Benutzer einen Passkey auf seinem Smartphone hat, aber sich am Laptop anmelden möchte: Hybrid Transport (CTAP 2.2) ermöglicht die Authentifizierung über Bluetooth LE + Internet. Der Browser zeigt einen QR-Code, das Smartphone scannt ihn, baut eine verschlüsselte Verbindung auf und signiert die Challenge. Proximity Check über Bluetooth stellt sicher, dass das Smartphone physisch in der Nähe ist — ein Remote-Angreifer kann den QR-Code nicht nutzen.

Enterprise Deployment — Passkeys im Unternehmen einführen

Die Enterprise-Einführung von Passkeys erfordert eine schrittweise Migration, da nicht alle Anwendungen und Systeme Passkeys sofort unterstützen. Der empfohlene Ansatz für 2026: Phase 1: Entra ID / Okta / Duo als Identity Provider für Passkey-basiertes SSO konfigurieren. Phase 2: Passkeys für Cloud-Anwendungen (Microsoft 365, Google Workspace, Salesforce) aktivieren — diese unterstützen alle WebAuthn/FIDO2. Phase 3: On-Premise-Systeme über SAML/OIDC-Federation an den Identity Provider anbinden. Phase 4: Passwort-Fallback schrittweise deaktivieren — zuerst für Administratoren, dann für alle Benutzer.

• Microsoft Entra ID + Passkeys (2026): Entra ID unterstützt Passkeys vollständig: Entra Admin Center → Protection → Authentication methods → FIDO2 Security Key → Enable. Seit 2025 auch synced Passkeys (Microsoft Authenticator App, iCloud Keychain, Google Password Manager). Conditional Access Policy: „Require phishing-resistant MFA“ erzwingt Passkeys/FIDO2 und blockiert SMS-OTP, App-Notifications und andere phishing-anfällige Methoden.
• Recovery-Strategie: Das größte Deployment-Risiko: Was passiert, wenn der Benutzer seinen Authenticator verliert? Lösungen: 1) Mindestens 2 Passkeys pro Benutzer registrieren (z. B. Smartphone + YubiKey als Backup). 2) Temporary Access Pass (TAP) in Entra ID — ein zeitlich begrenzter Einmalcode für die Neuregistrierung. 3) Self-Service Recovery über verifizierten zweiten Kanal (z. B. SMS an verifizierte Nummer + Manager-Genehmigung). 4) Helpdesk-basierte Recovery mit Identity Verification (Video-Call + Ausweiskontrolle).
• Passkey-Richtlinie per MDM: Über Intune oder JAMF können Sie die Passkey-Nutzung auf verwalteten Geräten steuern: Welche Authenticator-Typen erlaubt sind (nur Hardware-Keys, nur Plattform-Authenticator, oder beides), ob Attestation erforderlich ist, und welche AAGUID (Authenticator Attestation GUID) akzeptiert werden. Für BYOD-Szenarien: Conditional Access mit Device Compliance — nur Geräte mit aktuellem OS und aktiviertem Geräteschutz (Biometrie, PIN) dürfen Passkeys synchronisieren.
• Legacy-System-Integration: Nicht alle Systeme unterstützen WebAuthn nativ. Lösungen: SAML/OIDC-Federation über den Identity Provider (Entra ID, Okta) — die Legacy-App authentifiziert über SAML, der IdP erzwingt Passkeys. Reverse Proxy mit WebAuthn (z. B. Authelia, Authentik) — der Proxy übernimmt die Passkey-Authentifizierung, bevor der Benutzer zur Legacy-App weitergeleitet wird. Für RDP/SSH: YubiKey PIV (Smartcard-Emulation) oder SSH-FIDO2 (OpenSSH 8.2+ unterstützt [email protected]).

Herausforderungen & Zukunft — was noch zu lösen ist

Trotz der enormen Sicherheitsvorteile gibt es 2026 noch offene Herausforderungen: Account Recovery bleibt das größte UX-Problem — wenn ein Benutzer alle Authenticatoren verliert und kein Backup existiert, ist der Account-Zugriff verloren (oder muss über unsichere Kanäle wiederhergestellt werden, was das Sicherheitsniveau senkt). Shared Accounts (z. B. gemeinsame Admin-Accounts, Kiosk-Systeme) sind für Passkeys nicht konzipiert — jeder Passkey ist an eine Person gebunden. Cross-Platform-Sync funktioniert innerhalb eines Ökosystems (Apple ↔ Apple, Google ↔ Google), aber nicht übergreifend — ein iPhone-Passkey kann nicht nativ auf einem Windows-PC synchronisiert werden (nur über Hybrid Transport oder Drittanbieter wie 1Password). Die FIDO Alliance arbeitet mit dem Credential Exchange Protocol (CXP) an einer Lösung für plattformübergreifenden Passkey-Export.

• AitM-Resistenz validieren: Passkeys schützen gegen Phishing und AitM — aber nur, wenn sie korrekt implementiert sind. Testen Sie mit EvilGinx2 (Reverse-Proxy-basiertes AitM-Tool): Wenn Ihre Passkey-Implementierung korrekt ist, scheitert der Angriff, weil die Origin nicht übereinstimmt. Wenn Sie Fallback auf Passwort + OTP erlauben, kann EvilGinx diese abfangen — der Passkey schützt nur, wenn er die einzige Authentifizierungsmethode ist.
• Passkeys für IoT und Embedded Systems: IoT-Geräte (Kameras, Sensoren, Industriesteuerungen) haben oft keine Benutzerinteraktionmöglichkeit für biometrische Verifizierung. Lösung: Device-Bound Passkeys mit automatischer Attestation — das Gerät authentifiziert sich über sein eingebautes Secure Element, ohne Benutzerinteraktion. Für Machine-to-Machine (M2M): mTLS mit X.509-Zertifikaten bleibt die bevorzugte Lösung.
• Post-Quantum-Readiness: Aktuelle Passkeys verwenden ECDSA (P-256) oder Ed25519 — beide sind nicht post-quantum-sicher. Ein zukünftiger Quantencomputer könnte den privaten Schlüssel aus dem öffentlichen berechnen. Die FIDO Alliance arbeitet an PQC-fähigen Passkeys mit ML-DSA (CRYSTALS-Dilithium) als Signaturalgorithmus. Zeitrahmen: Draft-Spezifikation 2026, erste Implementierungen 2027. Für die nächsten 5-10 Jahre sind aktuelle Passkeys sicher — ein „Harvest now, decrypt later“-Angriff funktioniert bei Challenge-Response nicht, da die signierte Challenge nach Sekunden wertlos ist.