Passkeys: Die langgesuchte Ablösung der Passwörter

Problem

Passwörter sind seit fünfzig Jahren das dominante Authentifizierungsverfahren im Internet und seit vermutlich ebenso langer Zeit als fundamental unsicher eingestuft. 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 Datenleck 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. Kommt eine Passwort-Datenbank "abhanden" und die Hashes (Einweg-Prüfsummen der Passwörter) sind nicht oder nur schwach "gesalzen" (Salting, ein Begriff aus der Kryptologie: jedem Passwort wird vor dem Hashen ein Zufallswert beigemischt), lassen sich die zugehörigen Nutzerpasswörter (in Klarschrift!) oft binnen Stunden rekonstruieren.

Noch schlimmer: Passwort vergessen - wenn das E-Mail-Passwort erbeutet wird, kann der Angreifer durchgehen und bei allen Diensten neue Passwörter anfordern - und dann alles sofort übernehmen. Man kommt dann selbst nicht mehr an die Dienste und seine Mails. Die Wiederherstellung kann Monate dauern mit extrem hohen finanziellen und persönlichen Reputationsschäden.

All diese Probleme lassen sich abschwächen, MFA (Multi-Faktor-Authentisierung, Anmeldung mit mehr als einem Nachweis) gegen Ausspionieren ("shoulder surfing", das Mitlesen über die Schulter) und Passwörter erraten (bzw. systematisch durchprobieren), Passwort-Manager mit individuellen Passwörtern gegen Wiederverwendung und Phishing-Klickfalle, starke Hash-Verfahren wie Argon2 gegen Offline-Angriffe (anbieterseitig), aber keine dieser Abschwächungen löst die strukturelle Schwäche des Modells "geheimes Wissen, das an den Server übertragen wird".

Für wen ist das? Für alle, die Logins betreiben oder ihre Anmeldung sicherer machen wollen.

Kurze Antwort

Passkeys ersetzen das geheime Passwort durch ein Schlüssel-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 (z.B. Biometrie wie Fingerabdruck oder Geräte-PIN).

Drei Eigenschaften fallen dabei strukturell ab:

• Es gibt nichts zu phishen: die Signatur passt nur zur echten Webseite. Täuschend echt nachdesignte Seiten werden sofort erkannt
• Es gibt nichts wiederzuverwenden: pro Dienst existiert ein eigenes Schlüsselpaar
• Es gibt nichts zu erraten: Die Schlüsselpaare sind so lange, dass das Ausprobieren länger dauern würde als das gesamte Universum bereits existiert

Tiefgang

Das Protokoll: WebAuthn + CTAP2

Passkeys sind die Nutzer-freundliche Bezeichnung für Discoverable Credentials (auf dem Gerät auffindbare Anmelde-Schlüssel) aus der WebAuthn-Spezifikation (Level 2, Level 3 in Entwicklung). Darunter liegt die FIDO2-Allianz (FIDO, ein Industriekonsortium für passwortlose Anmeldung) aus zwei Standards:

• WebAuthn (W3C, das Standardisierungsgremium des Web): Browser-API (Programmierschnittstelle), über die eine Relying Party (also die Website, die die Anmeldung entgegennimmt) Registrierung und Authentifizierung anstösst.
• CTAP2 (Client to Authenticator Protocol): wie der Browser mit dem Authenticator (dem Gerät, das den Schlüssel hält und signiert) 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 (Origin = Schema + Host + Port, also die exakte Herkunftsadresse). 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 (eine einmalige Aufgabe, die signiert werden muss). 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, BitWarden, ...) 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, ein tragbarer Schlüssel zum Anstecken). YubiKey, Nitrokey, Titan Key. Der Schlüssel existiert genau einmal, auf einem 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, der ins Gerät eingebaute Schlüsselspeicher). 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 zu 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 (SS7 = Signalisierungsprotokoll im Telefonnetz mit bekannten Abhör-Lücken)
• Per Support-Team mit Identitätsprüfung: teuer und langsam

Eine saubere Implementierung verlangt mehrere Passkey-Registrierungen von Anfang an (zweites Gerät 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
2. Discoverable Credentials (resident, also dauerhaft auf dem Gerät gespeichert) werden angefordert, sodass der Login ohne vorherige E-Mail-Eingabe funktioniert (Conditional UI, der automatische Passkey-Vorschlag des Browsers)
3. userVerification: required wird beim Registrierungs- und Login-Flow gesetzt, denn nur dann ist der Authenticator verpflichtet, Biometrie oder PIN zu prüfen

Fehlt einer dieser drei Punkte, ist die Implementierung eher WebAuthn-2FA (ein zweiter Faktor zusätzlich zum Passwort) als echte Passkey-Authentisierung.

Abgelehnte Alternativen und Mythen

SMS-OTP als "zweiter Faktor". OTP (One-Time-Password, Einmal-Code) per SMS ist phishbar (die echte Seite liefert den Code an den Angreifer-Proxy), SS7-abfangbar, SIM-Swap-anfällig (ein Angreifer lässt Ihre Nummer auf eine eigene SIM umschreiben). SMS ist besser als nichts, aber strukturell unterlegen.

TOTP (Google Authenticator, Authy). TOTP (zeitbasierter Einmal-Code aus einer App) ist 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. Erhöht den Aufwand, macht den Angriff aber nicht unmöglich.

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

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

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

Was Sie jetzt tun sollten

Ob als Nutzer oder als Betreiber eines Dienstes - der Einstieg in Passkeys lässt sich planvoll angehen:

1. Bei wichtigen Konten Passkeys aktivieren. Richten Sie für E-Mail, Bank und Cloud-Speicher dort einen Passkey ein, wo der Anbieter es anbietet, statt allein auf das Passwort zu setzen.
2. Mindestens einen zweiten Passkey hinterlegen. Registrieren Sie ein zweites Gerät oder einen Hardware-Key, damit der Verlust eines Geräts nicht den Account-Zugang kostet.
3. Wiederherstellung vorab klären. Hinterlegen Sie Backup-Codes oder einen zweiten Kanal, bevor Sie auf das Passwort verzichten - die Wiederherstellung ist der schwächste Punkt.
4. Als Betreiber die drei Prüfsteine umsetzen. Erlauben Sie mehrere Credentials pro Konto, fordern Sie Discoverable Credentials an und setzen Sie userVerification: required.
5. Eine fertige Bibliothek nutzen. Bauen Sie WebAuthn nicht selbst nach, sondern setzen Sie auf eine etablierte Open-Source-Bibliothek und stecken Sie den Aufwand in die Wiederherstellungs-Strategie.

Wie Dernium hier hilft

Derniums gesamtes Ökosystem ist passkey-first gebaut: Discoverable Credentials per WebAuthn Conditional UI als Primär-Faktor, Magic-Link (Anmeldung per Einmal-Link in einer E-Mail) als Fallback für Geräte ohne Passkey-Unterstützung, optional TOTP als zweiter Faktor. Ein Passwort ist nicht vorgesehen, auch nicht als optional! Mehrere Passkey-Registrierungen pro Account sind Pflicht, damit der Verlust eines Geräts nicht zum Account-Totalverlust führt. Für die detaillierte Umsetzung gibt es einen eigenen Beitrag in dieser Serie, der den Login-Flow Schritt für Schritt durchgeht.

Offene Punkte

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

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 (der kryptografische Herkunftsnachweis eines Authenticators) aus. Die Standards (Device-Attestation, Enterprise Attestation) existieren, die Produktreife ist uneinheitlich.

Häufige Fragen

Was passiert, wenn ich mein Gerät mit dem Passkey verliere?

Wenn Sie nur einen einzigen Passkey hatten, kann der Verlust den Zugang kosten - genau deshalb ist mehr als ein Passkey wichtig. Bei synchronisierten Passkeys liegt der Schlüssel verschlüsselt in der Cloud Ihres Anbieters und steht auf einem neuen Gerät wieder bereit. Bei Hardware-Keys brauchen Sie einen vorab registrierten Ersatz-Key oder hinterlegte Backup-Codes.

Sind Passkeys wirklich sicherer als ein langes Passwort im Passwort-Manager?

Ja, weil sie eine andere Klasse von Angriffen ausschließen. Ein langes Passwort schützt vor Erraten, lässt sich aber weiterhin abphishen oder bei einem Datenleck als Hash erbeuten. Ein Passkey signiert nur für die echte Domain und überträgt kein Geheimnis an den Server, das gestohlen werden könnte. Beides ergänzt sich, aber Passkeys nehmen die strukturelle Schwäche heraus.

Geben Passkeys meinen Fingerabdruck oder mein Gesicht an die Webseite weiter?

Nein. Die biometrische Prüfung läuft ausschließlich lokal auf Ihrem Gerät und entsperrt dort den privaten Schlüssel. Die Webseite erfährt nur, dass die Nutzer-Verifikation erfolgreich war, niemals das biometrische Merkmal selbst.

Brauche ich für jeden Dienst einen eigenen Passkey?

Im Ergebnis ja, aber das geschieht automatisch: Pro Dienst wird ein eigenes Schlüsselpaar erzeugt. Sie merken sich nichts und verwalten nichts manuell; Ihr Gerät oder Passwort-Manager ordnet beim Login den passenden Passkey der jeweiligen Domain zu. Dass jeder Dienst ein eigenes Paar hat, ist gerade der Grund, warum ein Leck bei einem Dienst andere nicht gefährdet.

Kann ich Passkeys nutzen, ohne mein Passwort sofort zu löschen?

Ja, und das ist sogar der empfohlene Übergang. Aktivieren Sie zunächst Passkeys parallel zum bestehenden Passwort und prüfen Sie, dass Login und Wiederherstellung zuverlässig funktionieren. Erst wenn mehrere Passkeys und ein Wiederherstellungsweg eingerichtet sind, können Sie das Passwort gefahrlos entfernen, sofern der Dienst das anbietet.