Passkeys reichen nicht: Gerätgebundene Sessions in 90 Tagen ausrollen

Passkeys haben den Großteil der Passwort-Phishing-Angriffe eliminiert. Angreifer haben sich angepasst. Sie greifen nicht mehr Ihre Login-Maske an, sondern stehlen das, dem Sie mehr vertrauen als Passwörtern: langlebige Session-Tokens. Chrome rollt jetzt gerätgebundene Sessions aus, und OAuth hat endlich eine praxistaugliche Proof‑of‑Possession‑Lösung. Wenn Sie das in den nächsten 90 Tagen nicht angehen, kalkulieren Sie ATO‑Schäden ein.

Was sich gerade geändert hat (und warum es Sie interessieren sollte)

Zwei Signale sind gleichzeitig gelandet. Erstens beginnt Chrome mit dem, was es device‑bound sessions nennt (weitgehend als bisher stärkste Browser‑Verteidigung gegen Kontoübernahmen berichtet). Übersetzung: Ein browserverwalteter Schlüssel bindet eine Session an ein bestimmtes Gerät, sodass ein gestohlenes Cookie anderswo nicht wiederverwendet werden kann. Zweitens hat neue Forschung frische Fallstricke in realen Passkey‑Deployments aufgezeigt – clevere Social‑Engineering‑Tricks und Recovery‑Lücken, die WebAuthn komplett umgehen. Zusammen bestätigen sie, was Ihre Incident‑Queue bereits weiß: Passkeys härten Schritt eins, aber Tokens entscheiden, wer gewinnt.

Nichts davon ist theoretisch. Reverse‑Proxy‑Phishing‑Kits (Evilginx u. a.) und Commodity‑Infostealer zielen gezielt auf Session‑Cookies, weil sie 2FA und Passkeys aushebeln. Fragen Sie jedes große SaaS: Die Wiederverwendung gestohlener Sessions übertrifft klassisches Passwort‑Phishing um Längen. Passkeys sind nicht der Endzustand; gerätgebundene Sessions schon.

Bedrohungsmodell 2026 aktualisieren

• Hauptangreiferverhalten: Replay gestohlener Sessions und Refresh Tokens, erlangt per Malware, Reverse Proxies oder fehlkonfigurierte Drittanbieter‑SDKs. Sie umgehen Ihre Auth‑Mauer vollständig.
• Wo Sie angreifbar sind: Lange Session‑Lebensdauern, Refresh Tokens, die von jedem Gerät nutzbar sind, lasche Rotation und Recovery‑Pfade (E‑Mail/SMS‑Supportflows), die neue, geräteagnostische Sessions ausstellen.
• Warum jetzt: Chromes gerätgebundene Sessions beginnen, die Replay‑Lücke clientseitig zu schließen. Serverseitig gibt Ihnen OAuths DPoP heute einen herstellerneutralen Weg, Tokens an einen pro‑Gerät‑Schlüssel zu binden. Sie müssen nicht warten, bis Browser‑Features ausgereift sind.

Ein Entscheidungsrahmen: Was zuerst ausrollen

Machen Sie daraus ein Reihenfolge‑, nicht ein Standards‑Debatten‑Problem. Nutzen Sie Traffic‑Mix und Risiko, um die Reihenfolge festzulegen.

• Traffic‑Mix: Wenn 55–70 % Ihrer Sessions auf Chrome laufen, planen Sie, gerätgebundene Sessions zu nutzen, sobald sie stabil ausgerollt sind. Aber parken Sie nicht auf einer Vendor‑Timeline – liefern Sie Proof‑of‑Possession jetzt mit DPoP für alle modernen Browser.
• App‑Surface: SPAs und native Apps können DPoP sofort übernehmen. Klassische server‑gerenderte Sites können dennoch die Ausgabe von Refresh/Tokens an einen gerätespezifischen Schlüssel binden und bei der Erneuerung Proof‑of‑Possession verlangen.
• Kundenprofil: Enterprise‑Kunden hinter brüchigen Proxys? Rollen Sie hinter einem Feature‑Flag aus und sorgen Sie für einen sauberen Fallback. Consumer‑Traffic im großen Stil? Priorisieren Sie schnellere Rotation und Telemetrie, um Token‑Wiederverwendung zu unterbinden.
• Recovery und Support: Wenn Ihr Helpdesk eine Session ohne Gerätebindung ausstellen kann, können Angreifer das auch. Beheben Sie Recovery parallel zu jeder Token‑Arbeit.

Der 30‑60‑90‑Plan

Tag 0–30: Stellen Sie das Ausstellen von Bearer‑Tokens ein, die Sie nicht verteidigen können

• Inventarisieren und verkürzen: Führen Sie Inventar über jedes von Ihnen ausgestellte Token (Session‑Cookies, API‑Tokens, Refresh Tokens). Setzen Sie eine aggressive Max‑Age für Access Tokens (10–15 Minuten) und verlangen Sie Rotation für Session‑Cookies mindestens alle paar Stunden. Verwenden Sie das __Host‑ Präfix, HttpOnly, Secure, SameSite=Strict, wo kompatibel.
• Gleitende Sessions ohne Nachweis beenden: Gleitende Erneuerungen sollten nur erfolgen, wenn der Client nachweisen kann, dass es dasselbe Gerät ist, das das Token ursprünglich erhalten hat.
• Diebstahl‑Telemetrie hinzufügen: Protokollieren Sie bei jedem Token eine Binding‑Key‑ID (vorerst Platzhalter), erfassen Sie User Agent, Plattform und grobe Geodaten. Alarmieren Sie bei Wiederverwendung von einem anderen Gerät/ASN – schon bevor Binding live ist.
• Recovery‑Bypässe blockieren: Eliminieren Sie SMS als Recovery‑Methode für Hochrisikokonten. Wechseln Sie zu Backup‑Codes + Hardware‑Key‑Fallback und verlangen Sie einen frischen Schritt zur Gerätebindung, um eine Post‑Recovery‑Session auszustellen.

Tag 31–60: Tokens per DPoP an Geräte binden

• Pro Gerät einen Schlüssel im Client erzeugen: Für SPAs mit WebCrypto einen ECDSA‑P‑256‑Schlüssel erstellen und in IndexedDB persistieren. Für native Apps den OS‑Schlüsselbund mit Hardware‑gestützter Speicherung nutzen (Secure Enclave auf iOS/macOS; StrongBox/TEE auf Android).
• OAuth DPoP für die Token‑Ausgabe übernehmen: Wenn der Client ein Access/Refresh Token anfordert, eine DPoP‑Proof einschließen, die mit dem Geräteschlüssel signiert ist. Der Server bindet das ausgegebene Token an diesen öffentlichen Schlüssel. Siehe RFC 9449.
• DPoP bei API‑Requests verlangen: Für Aufrufe, die mit einem Access Token authentifiziert werden, einen DPoP‑Header verlangen, der den Besitz des gebundenen Schlüssels beweist. Tokens ohne gültigen Proof oder mit abweichender Methode/URI ablehnen.
• Rotieren und attestieren: Beim Refresh einen neuen Proof verlangen. Erwägen Sie für Hochrisiko‑Tiers periodische Geräte‑Attestation auf Mobile (Play Integrity / DeviceCheck). Warten Sie nicht auf die Verfügbarkeit von Attestation – sie ist ein additives Signal.
• Overhead messen: Die Verifikation von ECDSA P‑256 fügt typischerweise ~0,3–0,9 ms CPU pro Request auf einem modernen Kern hinzu. Planen Sie grob 1–2 KB zusätzlichen Header pro Call ein. Das ist Rauschen im Vergleich zu den Kosten eines Supporttickets, ganz zu schweigen von einem Incident.

Tag 61–90: Browser‑native Gerätebindung aktivieren und den Kreis schließen

• Gerätgebundene Sessions dort aktivieren, wo unterstützt: Wenn Chromes Feature ausgerollt wird, beteiligen Sie sich für Ihre Primär‑Domain(s) und mappen Sie die browserverwaltete Bindung auf Ihre serverseitige Vorstellung eines Geräteschlüssels. Halten Sie DPoP als Cross‑Browser‑Baseline.
• Refresh‑Pfade härten: Jeder Pfad, der ein neues Token zurückgibt, muss Proof‑of‑Possession verlangen. Kein PoP, kein Token. Das gilt für OAuth Device Code Flows, PKCE‑Exchanges und vom Support ausgestellte Sessions.
• Incident‑Automatisierung: Bei Verdacht auf Diebstahl (Token ohne PoP oder mit neuem Geräteschlüssel gesehen) die gesamte Token‑Familie automatisch widerrufen, eine frische Gerätebindung erzwingen und den Nutzer benachrichtigen. Fügen Sie einen One‑Click‑Button „Das war ich nicht“ hinzu, der auf eine kontoweite Prüfung eskaliert.
• Recovery neu gestalten: Recovery erzeugt eine risikoarme, kurzlebige Session, die nur durch eine neue WebAuthn‑Zeremonie oder den Proof des Geräteschlüssels hochgestuft werden kann. Kein direkter Sprung zu einer langlebigen, voll privilegierten Session.

Referenzarchitektur: So sieht „gut“ aus

1. Geräteschlüssel‑Bootstrap: Beim ersten Sign‑in (Passkey/WebAuthn empfohlen) erzeugt der Client ein langlebiges Geräteschlüssel‑Paar (WebCrypto oder OS‑Schlüsselbund). Der öffentliche Schlüssel und eine zufällige Geräte‑ID werden bei Ihrem Auth‑Service registriert.
2. Token‑Ausgabe mit PoP: Der Client fordert Tokens mit einer DPoP‑Proof an. Der Auth‑Service bindet die Tokens (Access + Refresh + Session‑Cookie) an den öffentlichen Geräteschlüssel und gibt sie zurück. Cookies bleiben HttpOnly; PoP kommt in einen Header.
3. API‑Durchsetzung: Ihr API‑Gateway validiert das Token und verifiziert die DPoP‑Signatur gegen den gebundenen öffentlichen Schlüssel, Methode und URL. Abweichungen, Uhrdrift oder Wiederverwendung einer jti werden abgelehnt und gekennzeichnet.
4. Rotationsdisziplin: Access Tokens laufen nach 10–15 Minuten ab. Refresh Tokens sind Single‑Use und rotieren bei jedem Austausch. Session‑Cookies rotieren alle paar Stunden oder bei Privilegänderung. Alle Erneuerungen erfordern PoP.
5. Recovery und Step‑up: Recovery erstellt eine eingeschränkte Session, keinen Freifahrtschein. Jede Erhöhung (Billing, Datenexport, API‑Key‑Erstellung) erfordert entweder eine WebAuthn‑Assertion oder PoP vom gespeicherten Geräteschlüssel.
6. Telemetrie: Speichern und analysieren Sie „Device Binding Key ID × IP AS Number × Plattform“. Alarmieren Sie bei plötzlichem Geräteschlüssel‑Churn für einen Nutzer oder Wiederverwendung eines Binding‑Schlüssels über viele Accounts (bösartige Automatisierung).

Abwägungen und Stolpersteine (jetzt anerkennen)

• Nicht jeder Browser ist bereit: Gerätgebundene Sessions kommen uneinheitlich. Deshalb ist DPoP die Cross‑Browser‑Baseline. Halten Sie Fallbacks vor, aber lassen Sie sie PoP nicht stillschweigend umgehen.
• Corporate Proxies und API‑Gateways: Manche Middleboxes schreiben Header um. Schützen Sie DPoP‑Header Ende‑zu‑Ende (TLS‑Terminierung nur an Ihrem Edge) und dokumentieren Sie Anforderungen für Enterprise‑Kunden.
• Geteilte Accounts: Aufhören zu teilen. Implementieren Sie delegierten Zugriff und rollenbasierte API‑Keys, die an jeden Nutzer gebunden sind. Wenn es absolut sein muss, unterstützen Sie getrennte Gerätebindungen pro Operator und beschränken Sie Privilegien.
• Performance: PoP fügt Kryptographie‑Arbeit hinzu. Amortisieren Sie am Edge, cachen Sie Token‑Introspection und bevorzugen Sie ECDSA P‑256 gegenüber schwereren Kurven. In der Praxis ist die zusätzliche Latenz auf Commodity‑Hardware sub‑millisekundär.
• Schlüssellebenszyklus: Geräte werden ersetzt. Bieten Sie einen sauberen „Geräteschlüssel außer Betrieb nehmen“‑Flow und benachrichtigen Sie bei neuen Gerätebindungen. Halten Sie eine kurze Liste (5–10) aktiver Geräteschlüssel pro Nutzer.
• Recht und Privacy: Das Binden an einen Geräteschlüssel ist kein Device‑Fingerprinting. Sie speichern einen öffentlichen Schlüssel, keinen Canvas‑Hash. Dokumentieren Sie es dennoch in Ihrer Datenschutzerklärung und geben Sie Nutzern Sichtbarkeit und Kontrolle.

Wie sich das mit Passkeys überschneidet (und wo Teams falsch abbiegen)

Passkeys beweisen beim Sign‑in, dass es die richtige Person auf einem echten Gerät ist. Danach verlagert sich das Risiko auf Tokens. Häufige Fehlermuster, die wir in Audits sehen:

• Passkey rein, Bearer raus: Teams rüsten den Login auf WebAuthn auf, stellen aber weiterhin ein Bearer‑Cookie aus, das jede Maschine wiederverwenden kann. Sie haben die Haustür verbessert und den Safe offen gelassen.
• Recovery‑Blindspots: SMS und E‑Mail‑Links stellen ungebundene Sessions aus. Verwenden Sie sie, um eine neue Gerätebindung zu bootstrappen – nicht, um sie zu umgehen.
• Lange Refresh‑Lebensdauern: 30‑Tage‑Refresh‑Tokens ohne PoP sind ein Geschenk für Infostealer. Rotieren Sie bei jeder Nutzung; lassen Sie ungenutzte Tokens schnell ablaufen.

KPIs, die Ihr Vorstand akzeptieren wird

• Rate der Wiederverwendung gestohlener Sessions: Ziel: 80 %+ Reduktion innerhalb von 90 Tagen nach Rollout, gemessen an Tokens ohne gültigen PoP oder mit neuer Gerätebindung.
• Time‑to‑Revoke: Von der ersten verdächtigen Token‑Nutzung bis zur familienweiten Revokation unter 60 Sekunden.
• Coverage: Prozentsatz aktiver Nutzersessions mit erzwungener Gerätebindung. 70 % bis Tag 60; 90 % bis Tag 120.
• Support‑Last: Weniger ATO‑Tickets pro Million MAU. Rechnen Sie mit einem kurzfristigen Anstieg, während Sie Lücken schließen, dann mit einem stetigen Rückgang.

Implementierungshinweise nach Plattform

• Web (SPA/MPA): Geräteschlüssel mit WebCrypto erzeugen; in IndexedDB speichern; DPoP mit SubtleCrypto signieren. Für MPA können Sie weiterhin einen Hintergrund‑„Device Key Service Worker“ betreiben, der Proofs für privilegierte POSTs signiert.
• Mobile: Hardware‑gestützte Schlüssel via Keychain (iOS) und Keystore (Android). Nutzen Sie Attestation, wo verfügbar. Binden Sie Tokens an diese Schlüssel; verlangen Sie PoP bei Refresh und sensiblen API‑Calls.
• Desktop (Electron/Tauri): OS‑Keychain‑APIs verwenden. Export der Private Keys verhindern. Erwägen Sie mTLS für interne Enterprise‑Deployments.
• Server und CLIs: Für Automatisierung kurzlebige OAuth Client Credentials oder eng zugeschnittene, PoP‑gebundene Service‑Tokens verwenden. Niemals langlebige Bearer‑Tokens in CI‑Secrets legen.

Rollout‑Strategie: Bruch minimieren, Wirkung maximieren

• Feature‑Flag nach Audience: Starten Sie mit Mitarbeiter‑Accounts, dann eine Kohorte hochriskanter Kunden, dann der Rest. Stellen Sie Self‑Service‑Gerätemanagement bereit, bevor Sie breit schalten.
• Schrittweise Durchsetzung: Eine Woche Log‑only‑Modus, dann Soft‑Enforcement beim Refresh, anschließend Hard‑Enforcement auf allen privilegierten Endpunkten.
• Kommunizieren – ernst gemeint: Erklären Sie die Änderung in Klartext: „Wir binden Sessions an Ihr Gerät, um Token‑Diebstahl zu verhindern. Sie sehen einmalig eine Aufforderung, dieses Gerät zu registrieren.“ Bieten Sie Backup‑Codes und klare Recovery‑Schritte.

Warum Nearshore hier wichtig ist

Das ist kein Moonshot; es ist ein diszipliniertes Engineering‑Projekt mit klaren Abnahmekriterien. Ein fokussiertes Nearshore‑Pod kann es End‑to‑End liefern – Änderungen am Auth‑Service, Durchsetzung im Gateway, Key‑Storage auf Mobile/Web, Telemetrie und SOC‑Playbooks – während Ihr Kernteam weiter Produkt ausliefert. Rechnen Sie mit 6–8 Wochen Arbeit für ein mittelgroßes SaaS (Web + Mobile) plus zwei Wochen gestuftem Rollout und Tuning.

Unterm Strich

Passkeys machen Phishing teuer. Gerätgebundene Sessions machen Token‑Diebstahl unprofitabel. Kombinieren Sie Browser‑Binding, sobald es landet, mit DPoP, das Sie heute deployen können – und Sie nehmen die größte ATO‑Klasse vom Tisch, ohne Ihren gesamten Auth‑Stack neu zu bauen. Wenn Sie dieses Quartal ein Security‑Projekt shippen, dann dieses.

Wichtigste Erkenntnisse

• Passkeys sind notwendig, aber nicht ausreichend; Angreifer spielen gestohlene Tokens wieder ein, um sie zu umgehen.
• Chromes gerätgebundene Sessions und OAuth DPoP schließen die Replay‑Lücke, indem sie Proof‑of‑Possession verlangen.
• In 90 Tagen liefern: Tokens verkürzen, Telemetrie hinzufügen, DPoP implementieren, dann Browser‑natives Binding aktivieren, sobald es ausgerollt wird.
• PoP bei jedem Refresh und jedem privilegierten API‑Call erzwingen; Recovery muss eine neue Gerätebindung bootstrappen, nicht sie umgehen.
• Erwarten Sie sub‑millisekundären Krypto‑Overhead und einen messbaren Rückgang von ATO‑Incidents innerhalb eines Quartals.