Passkeys vs. Passwörter: Wie WebAuthn wirklich funktioniert, wer was anbietet und wie man es einführt

Ein Passwort ist ein Geheimnis, das zwei Parteien gleichzeitig aufbewahren müssen: Sie selbst und jeder Server, in den Sie es je eingetippt haben. Das ist der eigentliche Konstruktionsfehler. Es spielt keine Rolle, wie lang oder zufällig die Zeichenfolge ist — wenn sie getippt werden kann, kann sie gephisht werden, und wenn sie noch irgendwo anders gespeichert ist, kann sie durch einen Breach abgegriffen und wiederverwendet werden.

Ein Passkey ist kein stärkeres Geheimnis. Auf Serverseite ist er überhaupt kein Geheimnis. Er ist eine Hälfte eines Schlüsselpaars, und die Hälfte, die der Server bekommt, ist für einen Angreifer mathematisch wertlos.

Diese Unterscheidung geht in den meisten “Aktiviere Passkeys”-Marketingtexten unter, was schade ist, denn das zugrunde liegende Protokoll ist wirklich elegant und lohnt sich, es auf Nachrichtenebene zu verstehen — besonders wenn Sie es implementieren müssen. Dieser Artikel behandelt, wie die beiden zentralen WebAuthn-Zeremonien tatsächlich funktionieren, was “synchronisiert” versus “geräte-gebunden” wirklich bedeutet, wer 2026 Passkeys anbietet und was diese jeweils vorhalten, wie man Unterstützung implementiert, ohne die Kontowiederherstellung zu zerstören, und eine ehrliche Einschätzung, wo es noch hakt.

Was ein Passkey wirklich ist

Entfernt man das Produkt-Framing, ist ein Passkey ein WebAuthn-Public-Key-Credential, und WebAuthn ist ein W3C-Standard, der zusammen mit dem CTAP2-Protokoll der FIDO Alliance FIDO2 bildet. Drei Parteien sind an jeder Zeremonie beteiligt, und es lohnt sich, sie präzise zu benennen, weil die Anbieter-Dokumentation das selten tut:

• Die Relying Party (RP) — die Website oder App, die Sie authentifizieren möchte. Das ist Ihr Server. Er sieht, speichert oder überträgt zu keinem Zeitpunkt einen privaten Schlüssel.
• Der Client — Browser oder Betriebssystem, der zwischen dem JavaScript der RP (navigator.credentials) und dem Authenticator vermittelt und — das ist der wichtige Teil — den Origin unabhängig prüft, bevor irgendetwas signiert wird.
• Der Authenticator — das Ding, das den privaten Schlüssel tatsächlich hält: die Secure Enclave eines Smartphones, das TPM eines Laptops, oder ein Roaming-Hardware-Key (YubiKey, Titan). Er spricht nie direkt mit dem Netzwerk, sondern nur über CTAP2 mit dem Client.

Ein Passwort-Login hat zwei Parteien und ein gemeinsames Geheimnis. Ein Passkey-Login hat drei Parteien und null gemeinsame Geheimnisse — der öffentliche Schlüssel, der auf Ihrem Server liegt, darf per Definition geleakt werden. Das ist der ganze Punkt, und alles Weitere in diesem Artikel beschreibt, wie diese Eigenschaft erreicht wird und wo sie doch wieder mit einem “na ja, es ist kompliziert” zurückkommt.

Wie die Registrierung funktioniert

Einem Konto “einen Passkey hinzuzufügen” ist eine WebAuthn-Registrierungszeremonie (navigator.credentials.create()). Sechs Nachrichten, drei Parteien, und der private Schlüssel berührt genau eine davon.

Ein paar Details, die relevant werden, sobald man das tatsächlich implementiert:

• Die Challenge ist Einmalgebrauch und wird serverseitig erzeugt. Sie dient rein der Replay-Prävention — die Signatur, die der Authenticator am Ende erzeugt, ist nur für genau diese Challenge gültig, sodass eine abgefangene Registrierungsantwort nicht gegen eine andere Session wiederverwendet werden kann.
• Attestation ist optional und meist nicht erzwingenswert. Der Authenticator kann kryptografisch belegen, welches Modell er ist (attestation: "direct"), aber das leakt Geräte-Fingerprinting-Informationen, erfordert die Pflege eines Metadata-Trust-Stores, und die meisten Consumer-Flows nutzen attestation: "none". Direkte Attestation nur in regulierten Enterprise-Kontexten einsetzen, in denen eine bestimmte Hardware-Allowlist durchgesetzt werden muss.
• Entdeckbare (Resident) Credentials sind das, was “Passkey” vom alten WebAuthn-2FA unterscheidet. residentKey: "required" weist den Authenticator an, das Credential so zu speichern, dass es ohne vorherige Übermittlung eines Benutzernamens gefunden werden kann — genau das treibt die “Mit Passkey anmelden”-Kontoauswahl an, statt “Benutzernamen eingeben, dann Security-Key benutzen”.
• Credential-ID und öffentlicher Schlüssel sind das, was gespeichert wird — sonst nichts. Ein minimales Schema ist (user_id, credential_id, public_key_cose, sign_count, transports, created_at). sign_count ist ein Legacy-Anti-Klon-Zähler aus Einzelgeräte-Authenticatoren; die meisten synchronisierten Passkeys melden ihn konstant als 0 — als Hinweis behandeln, nicht als Sicherheitsgrenze.

Wie der Login funktioniert

Das Anmelden ist die Authentifizierungszeremonie (navigator.credentials.get()) und das Spiegelbild der Registrierung — eine Challenge geht raus, eine Signatur kommt zurück, nur dass der Server diesmal etwas hat, gegen das er die Signatur prüfen kann.

Das Detail, das die eigentliche Anti-Phishing-Eigenschaft liefert, überliest man leicht: der Client — nicht der Nutzer — prüft, ob der Origin, der die Assertion anfordert, mit dem Origin übereinstimmt, gegen den das Credential registriert wurde. Ein pixelgenauer Klon Ihrer Login-Seite auf einer Fake-Domain kann einen identischen navigator.credentials.get()-Aufruf rendern, und der Browser wird schlicht keine gültige Signatur dafür erzeugen. Es gibt kein “Passwort in die falsche Box eingetippt”-Fehlerbild, weil es keine Box gibt.

Zwei Implementierungshinweise:

• Conditional UI (Autofill) ist das, was sich wie ein Passwortfeld anfühlt. Ruft man get() beim Laden der Seite mit mediation: "conditional" auf, zeigt der Browser gespeicherte Passkeys im normalen Autofill-Dropdown des Benutzernamens an — das Login-Formular sieht also weiterhin wie ein einfaches Eingabefeld aus, bietet aber zusätzlich eine Ein-Klick-Passkey-Option. Das auszulassen ist der häufigste Grund, warum “wir haben Passkeys eingeführt”-Rollouts eine geringe Adoption erzielen: Nutzer sehen die Option nie, weil sie hinter einem separaten Button versteckt ist.
• User Verification (userVerification: "preferred" vs. "required") entscheidet, ob eine reine “Gerät ist anwesend”-Prüfung ausreicht oder ob die lokale biometrische/PIN-Entsperrung zwingend ist. Für alles jenseits eines trivialen Kontos sollte sie verpflichtend sein — sonst wird ein entsperrtes, unbeaufsichtigtes Gerät zu einem vollständigen Authentifizierungs-Bypass.

Wer den privaten Schlüssel tatsächlich hält

Hier wird das “nimm einfach Passkeys”-Versprechen weniger einfach, und es lohnt sich, präzise zu sein, weil es das Design der Kontowiederherstellung verändert.

Synchronisierte Passkeys leben in der Ende-zu-Ende-verschlüsselten Cloud eines Plattformanbieters und folgen dem Konto des Nutzers, nicht seinem Gerät:

• Apple synchronisiert über iCloud Keychain über macOS, iOS, iPadOS und visionOS hinweg, abgesichert durch die Apple ID und (zum Anzeigen) den Geräte-Passcode.
• Google synchronisiert über den Google Passwortmanager über Android, ChromeOS und Chrome auf jedem Betriebssystem, gebunden an das Google-Konto.
• Microsoft verankert Plattform-Passkeys an Windows Hello und das Microsoft-Konto; auf der Workforce-Seite fügt Entra ID Richtlinienkontrolle hinzu, welche Authenticatoren akzeptabel sind.
• 1Password, Bitwarden, Dashlane und andere Passwortmanager synchronisieren Passkeys über den eigenen Tresor, plattformübergreifend per Design — genau darum geht es bei einem Passwortmanager: nicht an einen OS-Anbieter gebunden zu sein.

Geräte-gebundene Passkeys sind das andere Modell: Der private Schlüssel wird in genau einem Stück Hardware erzeugt und niemals exportiert, gesichert oder synchronisiert — per Design. Das ist der Standard (und oft die einzige Option) bei FIDO2-Hardware-Security-Keys, und manche Enterprise-MDM-Richtlinien erzwingen das sogar für Plattform-Authenticatoren — Wiederherstellbarkeit gegen eine deutlich schmalere Angriffsfläche eingetauscht: Der Schlüssel kann nur durch physische Kompromittierung genau dieses einen Geräts exfiltriert werden.

Was noch nicht sauber funktioniert: Einen synchronisierten Passkey von einem Anbieter-Ökosystem in ein anderes zu übertragen. Ein in iCloud Keychain erzeugter Passkey taucht nicht im Google Passwortmanager auf. Die praktische Brücke über Ökosysteme hinweg ist der FIDO2-CTAP2-Hybrid-Transport — einen QR-Code auf einem Laptop scannen, auf dem Smartphone per Bluetooth bestätigen, und das Smartphone fungiert für diese Browser-Session als einmaliger Roaming-Authenticator. Das ist ein echt nützlicher Fallback für “ich bin am Rechner eines Freundes” oder eine Plattformlücke, aber der private Schlüssel verlässt das Smartphone nach wie vor nie, und es ist kein Migrationswerkzeug. Das Credential Exchange Protocol (CXP) der FIDO Alliance ist die Standardisierungsinitiative für einen sauberen anbieterübergreifenden Export/Import; Stand 2026 ist das noch früh.

Wer 2026 was anbietet

Für die meisten Teams ist die eigentliche Entscheidung nicht “sollen wir rohes WebAuthn implementieren”, sondern “auf welcher Ebene implementieren wir es”. Hier die Landschaft, grob geordnet von der Consumer-Plattform bis zur Identitätsinfrastruktur:

Die ehrliche Einschätzung: Wenn Ihr Produkt bereits hinter Okta, Auth0, Entra ID oder einer selbst gehosteten Keycloak-/Authentik-Instanz sitzt, ist das Aktivieren von Passkeys eine Konfigurationsänderung, kein Engineering-Projekt. Der IdP ist bereits die Relying Party; Sie aktivieren nur einen Credential-Typ, den er bereits kennt. Das im Folgenden beschriebene Engineering-Projekt gilt für den Fall, dass Sie selbst die Relying Party sind — Sie betreiben Ihren eigenen Auth-Stack und wollen Passkeys als vollwertiges Credential hinzufügen.

Wie man es tatsächlich implementiert

Angenommen, Sie sind die Relying Party. So sieht die Arbeit aus:

1. Eine Server-Library wählen — CBOR/COSE nicht von Hand parsen. Das WebAuthn-Wire-Format (Attestation-Objekte, COSE-Public-Keys, CBOR-kodierte Authenticator-Daten) ist genau die Art von Sache, bei der es leicht passiert, sie subtil falsch zu machen — auf eine Weise, die erst später als Sicherheitslücke auffällt. Eine gepflegte Library für den eigenen Stack verwenden: SimpleWebAuthn (TypeScript/Node, liefert auch einen Browser-Helper), webauthn4j (Java), Fido2NetLib (.NET), go-webauthn/webauthn (Go, der aktiv gepflegte Fork der ursprünglichen Duo-Labs-Library), py_webauthn (Python), webauthn-rs (Rust). Alle stellen ungefähr dieselben zwei Funktionen bereit: “Registrierungs-/Authentifizierungs-Optionen erzeugen” und “Registrierungs-/Authentifizierungs-Antwort verifizieren”.

2. Die Relying Party ID von Anfang an richtig setzen. Die rpID ist die Domain, an die das Credential gebunden wird (kein Schema, kein Port) — example.com, nicht https://example.com, und nicht app.example.com, falls es auch auf www.example.com gültig sein muss. Hier einen Fehler zu machen führt dazu, dass in einer Umgebung registrierte Passkeys in einer anderen still und leise nicht authentifizieren (ein sehr häufiger “funktioniert lokal, bricht in Staging”-Bug, weil localhost und die Staging-Subdomain unterschiedliche RP-IDs sind).

3. Resident Keys und Conditional UI von Tag eins an erzwingen, nicht als spätere Erweiterung — ein Passkey-Rollout ohne die Autofill-Kontoauswahl-UX erreicht nur einen Bruchteil der Adoption, weil Nutzer nie entdecken, dass es die Option gibt.

4. Kontowiederherstellung entwerfen, bevor man live geht, nicht nach dem ersten Support-Ticket. Das ist der Teil, den jedes “Passkeys hinzufügen”-Tutorial auslässt. Mindestens:

• Nutzern erlauben, mehr als einen Authenticator zu registrieren (Smartphone plus ein Backup-Security-Key, oder zwei synchronisierte Geräte) — ein Single Point of Failure mit einem unwiederbringlichen Credential ist schlimmer als ein Passwort.
• Einen Fallback-Pfad vorhalten (E-Mail-Magic-Link, bei der Registrierung generierte Backup-Codes, oder ein menschlich verifizierter Support-Flow) für den Fall, dass jeder registrierte Authenticator verloren ist.
• Explizit entscheiden, ob ein Downgrade auf Passwort/OTP pro Konto erlaubt ist, und falls ja, es hinter zusätzlicher Friktion absichern — das ist der Pfad, den ein Angreifer als Erstes probieren wird, sobald Passkeys direkten Credential-Diebstahl nutzlos machen.

5. Schrittweise migrieren, nicht als harten Cutover. Passkeys als zusätzliche Credential-Option neben bestehendem Passwort/MFA anbieten, bestehende Nutzer nach einem erfolgreichen Login zur Registrierung auffordern (wenn bereits eine vertrauenswürdige Session existiert, um die Registrierung zu autorisieren), und Passwort-Login erst dann entfernen, wenn die Registrierungsrate hoch und die Wiederherstellungspfade bewährt sind. Falls parallel an der Session-/Token-Ebene gearbeitet werden muss, siehe JWTs nicht in localStorage — die beiden Probleme (wie man authentifiziert, wie man jemanden authentifiziert hält) sind getrennt und werden häufig vermischt.

6. Die Fehlerpfade testen, nicht nur den Happy Path: ein Nutzer, der den biometrischen OS-Prompt abbricht, ein Browser ohne Plattform-Authenticator (ältere Desktop-Safari-/Firefox-Konfigurationen), ein Nutzer, der mitten in der Session von einem verlorenen Android-Smartphone auf ein neues iPhone wechselt. Passkeys degradieren anders als Passwörter, und “keine Fallback-UI für eine abgebrochene Zeremonie” ist der häufigste Bug in ersten Passkey-Implementierungen.

Was in der Praxis noch hakt

• Ökosystemübergreifende Migration ist wirklich noch unfertig. Ein Nutzer, der heute von Android auf iPhone wechselt, registriert Passkeys pro Website neu, außer er nutzte von Anfang an einen plattformübergreifenden Manager wie 1Password oder Bitwarden.
• Geräteverlust im Unternehmen ist ein operatives Problem, nicht nur ein kryptografisches. Jemandes Laptop mit geräte-gebundenen Firmen-Passkeys wird gestohlen — wer widerruft das, wie schnell, und legt der eigene IdP überhaupt einen sauberen Weg für Credential-Widerruf frei? Das testen, bevor man es braucht.
• Nicht jeder Nutzer hat ein passkey-fähiges Gerät. Ältere Smartphones, geteilte/Kiosk-Geräte und manche unternehmenseigene, gesperrte Rechner können keinen Plattform-Authenticator registrieren; ein echter Fallback wird gebraucht, kein angeflanschter Workaround.
• “Passkey” als Support-Begriff ist gerade deshalb verwirrend, weil er die Sync-Ökosystem-Frage verdeckt. Support-Mitarbeiter müssen wissen, dass sie fragen müssen, “mit welchem Gerät und welchem Konto” er erstellt wurde, weil der Wiederherstellungspfad für einen synchronisierten iCloud-Keychain-Passkey völlig anders ist als für einen geräte-gebundenen YubiKey.

Fazit

Die Kryptografie ist nicht der schwierige Teil — WebAuthn ist ein gut spezifiziertes, eng gefasstes Protokoll, und die oben beschriebenen Registrierungs-/Login-Zeremonien sind wirklich alles, was zum Kernaustausch gehört. Der schwierige Teil ist alles, was das Protokoll bewusst offenlässt: Kontowiederherstellung, Fallback-UX, und die Tatsache, dass “Passkey” leise für vier verschiedene Sync-Ökosysteme mit unterschiedlichen Fehlermodi steht, je nachdem, in welcher Anbieter-Cloud ein Nutzer gerade zufällig ist.

Wer noch kein Identity Provider ist, für den ist der pragmatische Schritt, dieses Problem von einem übernehmen zu lassen — Okta, Auth0, Entra ID, oder ein selbst gehostetes Keycloak/Authentik — und die eigene Engineering-Zeit in Kontowiederherstellung und Rollout-Reihenfolge zu stecken statt in CBOR-Parsing. Wer selbst die Relying Party ist, für den belohnt das Protokoll sorgfältiges Lesen weit mehr als die meisten Auth-Features, und die Auszahlung ist real: keine Passwort-Datenbank mehr, die man breachen kann, und keine Login-Seite mehr, die sich phishen lässt auf die Art, wie es dreißig Jahre lang funktioniert hat.