WebAuthn/Passkeys Implementierung im Detail: die Security-Perspektive

1. Das Grundprinzip: Public-Key-Kryptographie statt gemeinsamer Geheimnisse

Bei einem klassischen Passwort-basierten Login kennt sowohl der Nutzer als auch der Server das gleiche Geheimnis, wobei der Server im Idealfall nur einen Hash davon speichert. Trotzdem muss das Klartext-Passwort bei jedem Login-Vorgang übertragen werden, was Angriffsflächen wie Phishing-Seiten, kompromittierte Netzwerkpfade oder unsichere Speicherung im Browser eröffnet.

WebAuthn arbeitet fundamental anders: Bei der Registrierung erzeugt das Endgerät des Nutzers ein kryptografisches Schlüsselpaar, bestehend aus einem privaten und einem öffentlichen Schlüssel. Der private Schlüssel verlässt niemals das Endgerät oder den Sicherheitschip, während der öffentliche Schlüssel an den Server übertragen und dort gespeichert wird. Bei jeder Authentifizierung signiert das Endgerät eine vom Server gestellte Challenge mit dem privaten Schlüssel, und der Server prüft diese Signatur mit dem gespeicherten öffentlichen Schlüssel, ohne dass jemals ein geheimer Wert das Endgerät verlässt.

// Registrierungs-Ceremony: PublicKeyCredential im Browser erzeugen
async function registerPasskey(challengeFromServer, userId, userName) {
  const publicKeyOptions = {
    challenge: challengeFromServer, // Uint8Array, vom Server pro Request generiert
    rp: { name: 'Beispiel Shop', id: 'beispiel-shop.de' },
    user: {
      id: userId,          // Uint8Array, serverseitige, stabile Nutzer-ID
      name: userName,       // z.B. E-Mail-Adresse
      displayName: userName,
    },
    pubKeyCredParams: [
      { type: 'public-key', alg: -7 },   // ES256
      { type: 'public-key', alg: -257 }, // RS256 als Fallback
    ],
    authenticatorSelection: {
      userVerification: 'required',       // PIN/Biometrie zwingend
      residentKey: 'required',            // discoverable Credential für Passkey
    },
    timeout: 60000,
    attestation: 'none',
  };

  const credential = await navigator.credentials.create({ publicKey: publicKeyOptions });
  // credential.response enthält den öffentlichen Schlüssel -- an Server senden
  return credential;
}

2. Die Registrierungs-Ceremony im Detail

Der Registrierungsvorgang, in der WebAuthn-Spezifikation als Ceremony bezeichnet, beginnt damit, dass der Server eine zufällige, ausreichend lange Challenge generiert und an den Browser sendet, zusammen mit Informationen über die Relying Party, also den Dienst selbst, und dem angemeldeten Nutzer. Der Browser reicht diese Daten über die navigator.credentials.create()-API an den Authenticator weiter, also entweder einen Hardware-Sicherheitsschlüssel, den plattformeigenen Sicherheitschip eines Smartphones oder Laptops, oder eine Passkey-Cloud-Synchronisierung.

Der Authenticator fordert vom Nutzer eine lokale Verifikation an, etwa per Fingerabdruck, Gesichtserkennung oder Geräte-PIN, generiert anschließend ein neues Schlüsselpaar speziell für diese Relying Party und signiert eine Attestation, die belegt, dass der öffentliche Schlüssel tatsächlich von einem echten Authenticator stammt. Der Browser sendet den öffentlichen Schlüssel, die signierte Challenge und Metadaten wie die Credential-ID zurück an den Server, der diese Daten nach Prüfung dauerhaft mit dem Nutzerkonto verknüpft speichert.

3. Die Authentifizierungs-Ceremony im Detail

Beim eigentlichen Login generiert der Server erneut eine frische, zufällige Challenge und sendet sie zusammen mit der Liste bekannter Credential-IDs des Nutzers an den Browser. Über die navigator.credentials.get()-API wird diese Challenge an den Authenticator weitergereicht, der anhand der Credential-ID das passende, bei der Registrierung erzeugte Schlüsselpaar identifiziert.

Nach erneuter lokaler Nutzerverifikation signiert der Authenticator die Challenge zusammen mit zusätzlichen, sicherheitsrelevanten Daten wie der tatsächlichen Origin der aufrufenden Seite mit dem privaten Schlüssel und sendet die Signatur an den Browser zurück. Der Server prüft diese Signatur mit dem bei der Registrierung gespeicherten öffentlichen Schlüssel sowie die Origin-Angabe, und gewährt bei erfolgreicher Prüfung Zugriff, ohne dass jemals ein wiederverwendbares Geheimnis übertragen wurde.

4. Phishing-Resistenz als zentraler Sicherheitsvorteil

Der entscheidende Sicherheitsgewinn gegenüber Passwörtern, auch gegenüber Einmalcode-basierten Zweitfaktoren, liegt in der strukturellen Bindung eines WebAuthn-Credentials an die exakte Origin der Webseite, bei der es registriert wurde. Der Browser übermittelt bei jeder Authentifizierung automatisch die tatsächliche Origin der aufrufenden Seite an den Authenticator, und dieser verweigert die Signatur, sobald die Origin nicht mit der bei der Registrierung hinterlegten übereinstimmt.

Ruft ein Nutzer eine Phishing-Seite unter einer ähnlichen, aber abweichenden Domain auf, etwa beispiel-shop-login.de statt beispiel-shop.de, erkennt der Authenticator die Origin-Abweichung automatisch und verweigert jede Interaktion, ganz ohne dass der Nutzer selbst die Domain sorgfältig prüfen müsste. Dieser Mechanismus unterscheidet sich fundamental von Einmalcodes per SMS oder Authenticator-App, die ein Nutzer versehentlich auch auf einer Phishing-Seite eingeben kann, weil die Codes selbst keinerlei Origin-Bindung besitzen.

5. Discoverable Credentials: der Unterschied zwischen WebAuthn und echten Passkeys

Während WebAuthn als Web-API bereits seit Jahren existiert, meint der neuere Begriff Passkey konkret sogenannte Discoverable Credentials, bei denen die Referenz auf das Schlüsselpaar direkt auf dem Authenticator gespeichert wird, statt vom Server bei jedem Login mitgesendet werden zu müssen. Das erlaubt einen Login-Ablauf, bei dem der Nutzer nicht einmal mehr seinen Benutzernamen eingeben muss, weil der Browser passende, lokal gespeicherte Credentials direkt anzeigt.

Zusätzlich unterstützen moderne Betriebssysteme wie iOS, Android und Windows eine Cloud-Synchronisierung dieser Discoverable Credentials über den jeweiligen Plattform-Account, sodass ein einmal registrierter Passkey automatisch auf allen Geräten desselben Nutzers verfügbar ist. Diese Synchronisierung löst das frühere Kernproblem von Hardware-Sicherheitsschlüsseln, nämlich den Verlust des Zugangs bei Verlust des physischen Geräts, ohne die kryptografische Sicherheit des zugrunde liegenden Mechanismus zu schwächen.

6. Conditional UI: Passkeys nahtlos in bestehende Login-Formulare integrieren

Eine besonders nutzerfreundliche Erweiterung von WebAuthn ist Conditional UI, bei der ein bestehendes Login-Formular mit einem klassischen Nutzername- und Passwortfeld erhalten bleibt, der Browser aber zusätzlich passende, lokal gespeicherte Passkeys direkt im Autofill-Dropdown des Nutzername-Felds anzeigt. Der Nutzer kann dadurch wahlweise sein Passwort eingeben oder mit einem Klick auf den vorgeschlagenen Passkey per Biometrie einloggen, ohne dass die Seite zwei getrennte Formulare oder Buttons anzeigen muss.

Technisch wird Conditional UI über das Attribut autocomplete="username webauthn" auf dem Eingabefeld sowie die Option mediation: 'conditional' beim Aufruf von navigator.credentials.get() aktiviert, wobei der Request bereits beim Laden der Seite im Hintergrund gestellt wird und erst bei tatsächlicher Nutzerinteraktion mit dem Autofill-Vorschlag abgeschlossen wird. Dieser Ansatz erleichtert die schrittweise Migration bestehender Passwort-Formulare erheblich, da keine strukturelle Änderung am sichtbaren Formular nötig ist.

7. Fallback-Strategie für Nutzer ohne WebAuthn-fähiges Gerät

Trotz breiter Unterstützung in modernen Betriebssystemen und Browsern gibt es weiterhin Nutzer mit älteren Geräten, restriktiven Unternehmensumgebungen oder besonderen Zugänglichkeitsanforderungen, die WebAuthn nicht nutzen können. Ein produktionsreifes System braucht deshalb zwingend einen Fallback-Pfad, der jedoch selbst nicht zum schwächsten Glied der Sicherheitskette werden darf.

Bewährt hat sich ein Fallback über Passwort in Kombination mit einem Zweitfaktor, etwa einer TOTP-App, statt reinem Passwort-Login ohne zusätzliche Absicherung. Wichtig ist zudem, den Fallback-Pfad nicht heimlich einfacher zu gestalten als den WebAuthn-Pfad, denn ein Angreifer wird gezielt den schwächeren der beiden Wege angreifen. Manche Systeme bieten deshalb WebAuthn als verpflichtenden zweiten Faktor zusätzlich zum Passwort an, statt es als vollständigen Passwortersatz zu betrachten, bis die Passkey-Adoption ausreichend hoch ist.

8. Wichtige serverseitige Implementierungsdetails

Serverseitig muss jede Challenge zwingend zufällig, ausreichend lang und nur für einen einzigen Authentifizierungsversuch gültig sein, typischerweise mit kurzer Lebensdauer in einer serverseitigen Session gespeichert und nach Verwendung sofort invalidiert. Die Origin-Prüfung darf niemals dem Client überlassen werden, sondern muss serverseitig anhand der vom Authenticator signierten Client-Data erfolgen, da eine reine clientseitige Prüfung von einem Angreifer trivial umgangen werden kann.

Ebenso wichtig ist die Pflege eines Signature-Counters pro Credential, der bei jeder erfolgreichen Authentifizierung erhöhte Werte liefern sollte. Ein stagnierender oder sinkender Zählerwert kann auf ein geklontes Credential hindeuten, etwa bei einem kompromittierten Hardware-Authenticator, und sollte serverseitig als Warnsignal behandelt werden, auch wenn moderne Passkey-Implementierungen mit Cloud-Synchronisierung diesen Zähler teilweise nicht mehr zuverlässig erhöhen.

9. Fazit: WebAuthn als strukturell überlegener Authentifizierungsansatz

WebAuthn löst das Grundproblem passwortbasierter Systeme nicht durch zusätzliche Regeln oder Komplexitätsanforderungen, sondern durch einen fundamental anderen kryptografischen Ansatz, bei dem niemals ein wiederverwendbares Geheimnis das Endgerät des Nutzers verlässt. Die enge Bindung an die tatsächliche Origin macht Phishing strukturell wirkungslos, statt sich wie bei Passwörtern und Einmalcodes allein auf die Wachsamkeit des Nutzers zu verlassen.

Für eine produktionsreife Implementierung zählen neben der reinen Ceremony-Logik vor allem serverseitige Sorgfalt bei Challenge-Generierung und Origin-Prüfung sowie eine durchdachte, nicht schwächere Fallback-Strategie für Nutzer ohne passendes Gerät. Wer diese Bausteine sauber umsetzt, erreicht ein Sicherheitsniveau, das mit klassischen Passwörtern selbst mit striktester Passwort-Policy praktisch nicht erreichbar ist.

10. Zusammenfassung

11. FAQ: WebAuthn/Passkeys Implementierung: Das Wichtigste auf einen Blick