Passwörter sterben leise: was Passkeys praktisch anders machen

Problem

Passwörter sind seit fünfzig Jahren das dominante Authentifizierungsverfahren im Web und seit vermutlich ebenso langer Zeit als fundamental unsicher bekannt. Drei Schwächen machen sie zur systemischen Hypothek:

1. Wiederverwendung. Nutzer merken sich zwei bis fünf Passwörter und benutzen sie für dutzende Dienste. Ein Leak bei einem beliebigen Dienst kompromittiert Accounts bei vielen anderen.
2. Phishing. Ein Angreifer baut eine Seite, die aussieht wie die echte, und nimmt das eingegebene Passwort entgegen. Keine Schutzschicht im Browser oder beim Anbieter kann das verhindern, wenn der Nutzer tippt.
3. Brute-Force und Offline-Angriffe. Wird eine Passwort-Datenbank geleakt und die Hashes sind nicht oder schwach gesalzen, lassen sich die Klartexte oft binnen Stunden rekonstruieren.

Alle drei Probleme lassen sich abschwächen, MFA gegen Wiederverwendung und Brute-Force, Passwort-Manager gegen Wiederverwendung und Phishing-Klickfalle, starke Hash-Verfahren wie Argon2 gegen Offline-Angriffe, aber keine dieser Abschwächungen löst die strukturelle Schwäche des Modells "geheimes Wissen, das an den Server übertragen wird".

Kurze Antwort

Passkeys ersetzen das geheime Passwort durch ein Public-Key-Paar, das kryptografisch an die Domain des Anbieters gebunden ist. Das Gerät des Nutzers speichert den privaten Schlüssel, die Signaturerzeugung erfordert eine lokale User-Verifikation (Biometrie oder Geräte-PIN). Drei Eigenschaften fallen dabei strukturell ab:

• Es gibt nichts zu phishen: die Signatur passt nur zur echten Origin.
• Es gibt nichts wiederzuverwenden: pro Dienst existiert ein eigenes Schlüsselpaar.
• Es gibt nichts zu brute-forcen: kein übertragenes Geheimnis, keine offline-knackbare Datenbank.

Tiefgang

Das Protokoll: WebAuthn + CTAP2

Passkeys sind die Nutzer-freundliche Bezeichnung für Discoverable Credentials aus der WebAuthn-Spezifikation (Level 2, Level 3 in Entwicklung). Darunter liegt die FIDO2-Allianz aus zwei Standards:

• WebAuthn (W3C): Browser-API, über die eine Relying Party (also die Website) Registrierung und Authentifizierung anstösst.
• CTAP2 (Client to Authenticator Protocol): wie der Browser mit dem Authenticator spricht, per USB, NFC, Bluetooth, oder intern (Plattform-Authenticator wie Face ID, Windows Hello).

Die zentrale Garantie: das Credential ist an die Origin der Seite gebunden (Schema + Host + Port). Ein Passkey für https://bank.example.com lässt sich auf https://bank-login.example.org nicht verwenden, auch wenn die Fake-Seite grafisch identisch aussieht. Der Browser prüft die Origin vor dem Weiterreichen der Challenge an den Authenticator; der Authenticator signiert nur für genau diese Origin.

Der Signaturvorgang

Bei der Anmeldung schickt der Server eine zufällige Challenge. Der Browser reicht sie zusammen mit der Origin an den Authenticator. Der Authenticator prüft mit dem Nutzer die Präsenz (Fingerabdruck, Face-ID, PIN), signiert die Challenge zusammen mit der Origin mit dem privaten Schlüssel und gibt die Signatur zurück. Der Server verifiziert die Signatur gegen den ursprünglich registrierten öffentlichen Schlüssel.

Dabei gilt: der private Schlüssel verlässt den Authenticator nie. Bei Hardware-Authenticatoren (YubiKey, Titan Key) ist das eine physische Eigenschaft. Bei synchronisierten Passkeys (iCloud Keychain, Google Password Manager) ist es eine Vertrauensannahme an die Plattform, die den Schlüssel verschlüsselt synchronisiert.

Hardware-Passkey vs. synchronisierter Passkey

Zwei Ausprägungen, mit echtem Unterschied:

Hardware-Passkey (Roaming Authenticator). YubiKey, Nitrokey, Titan Key. Der Schlüssel existiert genau einmal, auf dem Stück Hardware. Verlust heißt kein Zugriff, daher sind Ersatz-Keys Pflicht. Dafür: absolut keine Cloud-Abhängigkeit, nicht über Plattformwechsel hinweg verlustanfällig.

Synchronisierter Passkey (Platform Authenticator). iCloud Keychain (Apple-Ökosystem), Google Password Manager, 1Password, Bitwarden. Der Schlüssel liegt verschlüsselt in der Cloud-Synchronisation; auf mehreren Geräten desselben Anbieters verfügbar. Verlust eines Geräts ist kein Problem, Plattformwechsel (Android → iOS) ist derzeit noch umständlich.

Für hochschutzbedürftige Konten ist die Kombination sinnvoll: ein synchronisierter Passkey für den Alltag, ein Hardware-Key als Wiederherstellungsmittel.

Account-Wiederherstellung: der schwächste Punkt

Passkeys lösen das Authentifizierungs-Problem, aber sie verschieben ein Kernproblem in die Wiederherstellung: wie kommt ein Nutzer zurück an seinen Account, wenn er alle Passkeys verloren hat? Die üblichen Antworten sind schlecht:

• Per E-Mail an eine vorab hinterlegte Adresse: verlagert das Risiko auf den E-Mail-Account.
• Per SMS-Token: phishbar, SS7-angreifbar.
• Per Support-Team mit Identitätsprüfung: teuer und inkonsistent.

Eine saubere Implementierung verlangt mehrere Passkey-Registrierungen von Anfang an (zweiter Device oder Hardware-Key), plus Backup-Codes oder einen zweiten Wiederherstellungskanal auf hoher Schwelle.

Was eine saubere Passkey-Implementierung auszeichnet

Drei Prüfsteine für eine Relying Party:

1. Mehrere Credentials pro Account sind möglich und werden aktiv gefordert, der Nutzer kann nicht nur einen Passkey registrieren.
2. Discoverable Credentials (resident) werden angefordert, sodass der Login ohne vorherige E-Mail-Eingabe funktioniert (Conditional UI).
3. userVerification: required wird beim Registrierungs- und Login-Flow gesetzt, nur dann ist der Authenticator verpflichtet, Biometrie oder PIN zu prüfen.

Fehlt einer dieser drei Punkte, ist die Implementierung eher WebAuthn-2FA als echte Passkey-Authentifizierung.

Abgelehnte Alternativen und Mythen

SMS-OTP als "zweiter Faktor". Phishbar (die echte Seite liefert den OTP an den Angreifer-Proxy), SS7-abfangbar, SIM-Swap-anfällig. SMS ist besser als nichts, aber strukturell unterlegen. FIDO2-Authenticator statt.

TOTP (Google Authenticator, Authy). Phishbar wie SMS, ein Angreifer-Proxy leitet den Code weiter. Besser als SMS, aber nicht phishing-resistent. Nutzbar als zweite Schicht neben einem phishing-resistenten primären Faktor.

"Passkeys sind nur für grosse Anbieter sinnvoll." Das Gegenteil ist wahr. webauthn-rs, SimpleWebAuthn und andere Bibliotheken machen die Integration in einen neuen Dienst überschaubar. Aufwand ist eher die Account-Wiederherstellungs-Strategie.

"Biometrie wird an den Server übertragen." Nein. Die biometrische Prüfung findet ausschliesslich auf dem Gerät statt; der Server erfährt nur "User Verification war erfolgreich", kein Bild, kein Template, kein Merkmal.

Wie Svelnor hier hilft

Svelnor Auth ist passkey-first gebaut: Discoverable Credentials per WebAuthn Conditional UI als Primaer-Faktor, Magic-Link als Fallback für Geräte ohne Passkey, optional TOTP als zweiter Faktor. Ein Passwort ist nicht vorgesehen, auch nicht als optionaler Pfad. Mehrere Passkey-Registrierungen pro Account sind Pflicht, damit der Verlust eines Geräts nicht zum Account-Totalverlust fuehrt. Für die detaillierte Umsetzung gibt es einen eigenen Beitrag in dieser Serie, der den Login-Flow Schritt für Schritt durchgeht.

Verifikation

• WebAuthn-Spezifikation: W3C WebAuthn Level 2 Recommendation, Level 3 in Entwicklung.
• FIDO2 / CTAP2: FIDO Alliance Specifications.
• Passkeys Overview: passkeys.dev.
• Testseite zum Experimentieren: webauthn.io.
• Open-Source-Bibliotheken: webauthn-rs (Rust), SimpleWebAuthn (Node.js), py_webauthn (Python).

Offene Punkte

Plattformübergreifende Synchronisation. Apple, Google und Microsoft haben jeweils eigene Passkey-Synchronisationen. Ein Passkey aus iCloud auf einem Android-Gerät zu nutzen, ist über QR-Code-Hybrid-Flows möglich, aber ergonomisch mässig.

Enterprise-Verwaltung. Wer Passkeys auf verwalteten Geräten ausrollen will, steht vor neuen Fragen: welcher Authenticator ist erlaubt, wie werden Passkeys beim Ausscheiden widerrufen, wie sieht Attestierung aus. Die Standards (Device-Attestation, Enterprise Attestation) existieren, die Produktreife ist uneinheitlich.