Der WebAuthn-Loop: Häufige Logikfehler beim "Passwortlosen" Handshake

Die Cybersicherheitsbranche erlebt derzeit den bedeutendsten Wandel seit Jahrzehnten: den Übergang von “shared secrets” (Passwörtern) zu “asymmetric proof of possession” (Passkeys). Basierend auf dem WebAuthn (FIDO2)-Standard versprechen Passkeys eine Zukunft, die vor Phishing, Credential Stuffing und der Ermüdung durch passwortbasierte Authentifizierung schützt.

Doch mit zunehmender Verbreitung im Jahr 2025 ist ein gefährlicher Trend sichtbar geworden. Sicherheitsforscher und Penetrationstester erkennen ein wiederkehrendes Phänomen, das als “WebAuthn Loop” bekannt ist. Es tritt auf, wenn ein technisch “nicht-phishbares” Protokoll durch fehlerhafte Implementierungslogik untergraben wird, insbesondere im Handshake zwischen Frontend-Anfragen und Backend-Überprüfung.

In diesem Deep Dive analysieren wir die technischen Diskrepanzen, die “Handshake-Fallen” und die kritischen Wiederherstellungs-Backups, die die Sicherheitslücken wieder öffnen, die Passkeys eigentlich schließen sollten.

1. Die Anatomie eines modernen WebAuthn-Handshakes

Um die Fehler zu verstehen, müssen wir zunächst sehen, wie der Handshake funktionieren soll. Anders als bei einer Passwortanmeldung, die einen einfachen String-Vergleich ist, umfasst eine WebAuthn-Zeremonie einen komplexen Drei-Wege-Austausch zwischen der relying party (deinem Server), dem Client (Browser/OS) und dem Authenticator (biometrischer Sensor oder Sicherheitsschlüssel).

Der Registrierungsfluss:

Challenge-Generation: Der Server sendet eine kryptografisch zufällige Challenge und eine Relying Party ID (RP ID).

Credential-Erstellung: Das Gerät des Nutzers generiert ein neues Public-Private-Key-Paar.

Attestation: Das Gerät sendet den öffentlichen Schlüssel, eine credentialID und ein “Attestation-Objekt” (Nachweis, dass der Schlüssel auf einem legitimen Gerät erstellt wurde) zurück an den Server.

Verifizierung: Der Server validiert die Signatur und speichert den öffentlichen Schlüssel.

Der Authentifizierungsfluss:

Assertion-Anfrage: Der Server sendet eine neue Challenge.

Signieren: Der Authenticator signiert die Challenge mit dem privaten Schlüssel.

Assertion-Verifizierung: Der Server nutzt den gespeicherten öffentlichen Schlüssel, um die Signatur zu überprüfen.

Der “Loop” beginnt, wenn Entwickler dieses komplexe kryptografische Spiel wie ein Standard-API-Formular behandeln.

2. Fehler #1: Der Origin- & RP ID Validierungs-Lücken

Das mächtigste Feature von WebAuthn ist die Origin-Bindung. Ein Passkey, der für bank.com erstellt wurde, kann nicht auf bänk.com (einer Homograph-Phishing-Seite) verwendet werden. Der Browser erzwingt dies strikt. Allerdings kontrolliert der Browser nur eine Seite des Vertrags.

Die technische Diskrepanz:

Viele Backend-Implementierungen verifizieren das clientDataJSON, das vom Authenticator zurückgegeben wird, nicht strikt. Während des Handshakes liefert der Authenticator ein base64-kodiertes Objekt, das den Ort angibt, an dem die Zeremonie stattfand.

Der Logikfehler: Wenn der Backend-Code nur die Signatur prüft, aber die manuelle Überprüfung des origin-Feldes innerhalb des clientDataJSON überspringt, entsteht eine “Relayed Phishing”-Gelegenheit. Ein Angreifer könnte eine legitime WebAuthn-Zeremonie durch eine bösartige Domain proxyen, und wenn das Backend nachlässig ist, akzeptiert es eine gültige Signatur von einem “ungültigen” Origin.

Der Fix 2025: Implementiere immer eine strikte Origin-Allowlist auf Serverseite. In einer Multi-Domain-Umgebung (z.B. brand.co.uk und brand.com) nutze die neu standardisierten Related Origin Requests (ROR), um RP IDs sicher über Domains hinweg zu teilen, ohne die Sicherheitsbar zu senken.

3. Fehler #2: Der “Statische Challenge” und Replay-Schwachstelle

Ein häufiger Fehler bei WebAuthn-Implementierungen ist die Behandlung der “Challenge” als bloßen Sitzungs-Identifikator anstatt eines kryptografischen Nonce.

Die technische Diskrepanz:

Die Challenge muss:

• Auf dem Server generiert werden.
• Hoch-entropy (mindestens 16 Bytes).
• Kurzlebig (zeitlich begrenzt).
• Einmalig.

Der Logikfehler: Einige Entwickler verwenden statische oder vorhersehbare Challenges (wie eine Nutzer-ID oder einen Zeitstempel), um die “stateless”-Eigenschaft ihrer APIs zu vereinfachen. Wird eine Challenge wiederverwendet oder über mehrere Sitzungen hinweg persistiert, kann ein Angreifer, der eine signierte Assertion abfängt, einen Replay-Angriff durchführen. Er benötigt nicht deinen privaten Schlüssel; er muss nur dein letztes gültiges “Proof” erneut an den Server schicken, der nicht prüft, ob diese Challenge bereits “verbraucht” wurde.

Der Fix 2025: Nutze das “Challenge-Store-Verify”-Muster. Speichere die Challenge in einem serverseitigen Cache (z.B. Redis) mit einer TTL von 60–120 Sekunden. Nach der Verifizierung der Signatur lösche die Challenge sofort aus dem Cache.

4. Fehler #3: Das “Recovery-Paradoxon” (Das schwächste Glied)

Dies ist der kritischste Logikfehler im “Passwordless”-Ökosystem. Passkeys sind grundsätzlich kaum phishingfähig. Aber was passiert, wenn ein Nutzer sein Telefon verliert?

Die technische Diskrepanz:

Um “Lock-outs” zu vermeiden, implementieren Dienste eine Kontowiederherstellung. Oft greifen sie auf “alte” Methoden zurück:

• SMS-Einmalpasscodes (OTP)
• E-Mail-Magical Links
• Sicherheitsfragen

Der Logikfehler: Wenn du eine SMS-OTP-Backup-Option anbietest, machst du deine Passkey-Implementierung effektiv bedeutungslos. Ein Angreifer wird nicht versuchen, die WebAuthn-Kryptografie zu knacken; er klickt einfach auf “Gerät verloren” und startet einen SIM-Swap oder Social Engineering, um die SMS zu intercepten.

Die Sicherheit des Kontos “schleift” zurück zum schwächsten Glied. Allein 2024 begannen über 22% der Sicherheitsverletzungen mit Credential Abuse, oft durch diese “Fallback”-Mechanismen.

Der Fix 2025:

Mehrere Passkeys empfehlen: Fordere Nutzer auf, ein Backup-Gerät (z.B. Laptop und Smartphone) oder einen Hardware-Token (YubiKey) zu registrieren.

Wiederherstellungscodes: Stelle “Einmal-Codes” bereit, die der Nutzer offline speichern muss.

Identitätsprüfung: Für hochsensible Konten, eine 24-Stunden-Wartezeit oder manuelle ID-Überprüfung vor der Passkey-Reset-Option.

5. Fehler #4: Attestations-Nachlässigkeit & Das “Virtuelle Authenticator”-Problem

Während der Registrierung kann der Server “Attestation” anfordern. Das ist ein digitales Zertifikat des Geräteherstellers (Apple, Google, Yubico), das bestätigt, dass der öffentliche Schlüssel in einer sicheren Umgebung oder einem Hardware Security Module (HSM) generiert wurde.

Die technische Diskrepanz:

Viele Bibliotheken setzen standardmäßig auf “attestation: none”, weil die Verifizierung von Attestationsnachweisen technisch schwierig ist und eine Liste vertrauenswürdiger Root-Zertifikate erfordert.

Der Logikfehler: Wenn du die Attestation ignorierst, kann dein Server nicht erkennen, ob der “Passkey” tatsächlich ein sicherer, hardwaregebundener Schlüssel ist oder ein software-emulierter “virtueller Authenticator” auf einem Angreifer-Script. Während “Synced Passkeys” (wie in iCloud) die Attestation komplexer gemacht haben, sollten Unternehmensumgebungen dennoch strenge Prüfungen durchsetzen.

Der Fix 2025: Nutze den FIDO Metadata Service (MDS3). Das ist eine zentrale Datenbank mit Eigenschaften von Authenticators. Mit MDS3 kannst du verifizieren, ob ein Passkey von einem Gerät mit Biometrie und hardwaregestütztem Speicher stammt, statt von einem headless Chrome-Browser.

6. Fehler #5: Frontend/Backend-Desynchronisation und das “Erfolgreiche Scheitern”

WebAuthn ist ein mehrstufiger Prozess. In vielen modernen SPAs (Single Page Applications), die mit React oder Next.js gebaut sind, übernimmt das Frontend den navigator.credentials-Aufruf, und das Backend die Verifizierung.

Die technische Diskrepanz:

Ein häufiger Fehler ist, dass das Frontend die Authenticator-Antwort “validiert” und dann einfach dem Backend sagt: “Der Nutzer hat es signiert, hier ist die ID, loggt ihn ein.”

Der Logikfehler: Das Backend darf niemals eine “Erfolg”-Meldung vom Frontend blind vertrauen. In mehreren CVEs 2024 (insbesondere bei einigen Next.js-Authentifizierungs-Wrapper) wurde festgestellt, dass ein Angreifer die WebAuthn-Überprüfung umgehen kann, indem er den API-Call des Frontends abfängt und einen “Success”-Status injiziert, den das Backend dann ohne tatsächliche kryptografische Überprüfung akzeptiert.

Der Fix 2025: Das Backend sollte die einzige Quelle der Wahrheit sein. Das Frontend transportiert nur die rohen Bytes vom Browser zum Server. Das Server muss die schwere Arbeit leisten: das authData parsen, clientDataJSON hashen und die RS256- oder ES256-Signaturüberprüfung durchführen.

7. Wie man “den Kreis schließt”: Eine Entwickler-Checkliste

Um ein wirklich sicheres passwortloses System aufzubauen, geh über die grundlegenden Tutorials hinaus und behebe diese Logikfehler direkt:

Strikte Origin-Überprüfung: Überprüfe nicht nur die Signatur. Parsen das clientDataJSON und stelle sicher, dass der Origin exakt deiner Domain entspricht.

Stateless ist gefährlich: Stelle sicher, dass deine Challenges zufällig, servergeneriert und nach Gebrauch verbraucht werden.

Das “Passkey-First”-UX: Wenn ein Nutzer einen Passkey hat, zeige das “Passwort”-Feld nicht standardmäßig an. Das verhindert Phishing, bei dem Nutzer in eine Passwort-Eingabe gelockt werden.

Audit deiner Fallbacks: Wenn du SMS als Backup nutzt, behandle es als “reduzierten Sicherheitszustand.” Benachrichtige den Nutzer per E-Mail und beschränke die Kontoberechtigungen 48 Stunden nach einer SMS-Wiederherstellung.

Verwende geprüfte Bibliotheken: Entwickle nicht dein eigenes WebAuthn-Handling. Nutze bewährte Bibliotheken wie SimpleWebAuthn, FIDO2-lib oder Managed Services wie Clerk, Auth0 oder Passkeys.io, die MDS3 und Origin-Validierung out-of-the-box unterstützen.

Fazit: Die Zukunft ist Passwortlos, nicht logiklos

Passkeys stellen einen monumentalen Fortschritt in der Sicherheit dar, sind aber keine “Set-and-Forget”-Lösung. Der WebAuthn-Loop zeigt, dass die größten Schwachstellen oft in den Übergängen liegen – den Handshakes zwischen Browser und Server sowie im Übergang von “sicher” zu “Wiederherstellung”.

Indem Entwickler die technischen Diskrepanzen zwischen Frontend-Komfort und Backend-Rigorosität angehen, können sie sicherstellen, dass das Versprechen “Passwortlos” tatsächlich erfüllt wird: eine Web, in der deine Identität dir gehört und niemand anderem.