WebAuthn & Passkeys – Login-Sicherheit ohne Phishing-Fallen

Ein Login ist oft der erste und wichtigste Schutzwall – und gleichzeitig ein häufiger Angriffsvektor. Klassische Passwörter scheitern in der Praxis selten an Kryptographie, sondern an Gewohnheiten: Wiederverwendung, schwache Varianten, Phishing und „MFA-Müdigkeit“ bei Push-Bestätigungen. Moderne Anmeldeverfahren auf Basis von Passkeys setzen genau dort an: Es gibt kein Passwort mehr, das abgefangen oder erraten werden kann, und die Anmeldung ist an die echte Zielseite gebunden.

Warum Passkeys Angriffe praktisch ausbremsen

Bei einem Passwort-Login reicht es Angreifern oft, das Geheimnis zu kennen. Das kann über Phishing, Keylogging, kompromittierte Passwortmanager, geleakte Datenbanken oder Credential-Stuffing passieren. Passkeys verändern dieses Modell: Statt „Wissen“ (Passwort) wird „Besitz“ (Gerät/Authenticator) mit lokaler Entsperrung (PIN/Biometrie) kombiniert.

Phishing-resistente Anmeldung statt „besserem Passwort“

Ein zentraler Vorteil ist die Bindung an die Domain: Ein Passkey, der für example.com angelegt wurde, funktioniert nicht auf examp1e.com. Selbst wenn eine Phishing-Seite identisch aussieht, kann sie den Passkey nicht für die falsche Herkunft (Origin) nutzen. Das reduziert eine ganze Klasse von Angriffen, die bei Passwörtern und vielen OTP-Verfahren (Einmalcodes) zuverlässig funktioniert.

Was bleibt: Kontoübernahme über Endgeräte und Sitzungen

Passkeys eliminieren nicht jedes Risiko. Wird ein Endgerät kompromittiert (Malware, Fernzugriff, gestohlene Entsperr-PIN), kann ein Angreifer unter Umständen trotzdem Aktionen im Konto ausführen – insbesondere, wenn bereits eine Session besteht oder Recovery-Mechanismen schwach sind. Zudem kann Social Engineering weiterhin dazu führen, dass Nutzer:innen neue Passkeys auf fremden Geräten registrieren, wenn Prozesse und Hinweise fehlen.

So funktioniert WebAuthn im Kern

Die technische Grundlage hinter Passkeys ist WebAuthn (Web Authentication), ein Standard für starke, kryptographische Authentifizierung im Browser und in Apps. Vereinfacht gesagt wird ein Schlüsselpaar erzeugt: Der private Schlüssel bleibt im Authenticator (z. B. Smartphone, Hardware-Key, TPM-gestützter Gerätespeicher), der öffentliche Schlüssel wird beim Dienst hinterlegt.

Registrierung: Schlüssel erzeugen und an die Seite binden

Bei der Registrierung fordert die Webseite den Browser auf, einen neuen Credential zu erstellen. Der Authenticator erzeugt ein Schlüsselpaar und verknüpft es mit der Domain. Der Dienst speichert nur den öffentlichen Schlüssel sowie Metadaten (z. B. Credential-ID). Dadurch entsteht kein „geteiltes Geheimnis“, das bei einem Servereinbruch wie ein Passwort-Hash offline angegriffen werden könnte.

Anmeldung: Challenge signieren statt Geheimnis senden

Beim Login sendet der Dienst eine zufällige Challenge. Der Authenticator signiert diese Challenge mit dem privaten Schlüssel. Der Dienst prüft die Signatur mit dem öffentlichen Schlüssel. Entscheidend: Es wird kein Passwort übertragen, und die Signatur ist ohne den privaten Schlüssel nicht reproduzierbar.

„Plattform“ vs. „Roaming“: Wo der Schlüssel liegt

In der Praxis existieren zwei Typen:

• Hardware-Sicherheitsschlüssel (Roaming Authenticator): physischer Key (USB/NFC/Bluetooth), portabel zwischen Geräten, häufig mit sehr klaren Sicherheitsgrenzen.
• Plattform-Authenticator: im Gerät integriert (z. B. Smartphone Secure Enclave/TEE, Windows Hello, macOS), komfortabel, oft mit Cloud-Synchronisation.

Beide Varianten können sicher sein. Die Risikoabwägung hängt davon ab, wie stark Endgeräte geschützt sind und wie Recovery/Offboarding organisiert wird.

Typische Stolperfallen bei Einführung und Betrieb

Viele Probleme entstehen nicht beim ersten Setup, sondern im Alltag: Gerätewechsel, Helpdesk-Fälle, verlorene Telefone oder die Frage, wie sich externe Dienstleister anmelden sollen.

Account-Recovery: der häufigste Rückfall zu unsicheren Wegen

Wenn der Recovery-Prozess schwach ist, hebelt er Passkeys aus. Beispiele: Support setzt Konten nach Telefonanruf zurück, E-Mail-Postfach ist nur passwortgeschützt, oder „Notfallcodes“ liegen unverschlüsselt im Chat. Recovery ist deshalb wie ein eigener Authentifizierungsfaktor zu behandeln: dokumentiert, geprüft, mit klaren Identitätsnachweisen.

Gerätemanagement: ohne Basishygiene wird es teuer

Passkeys profitieren stark von sauberem Geräteschutz: Betriebssystem-Updates, Bildschirmsperre, Vollverschlüsselung, Malware-Schutz und die Fähigkeit, verlorene Geräte zu sperren oder zu löschen. In Unternehmen gehört dazu MDM/Endpoint-Management und ein definierter Prozess für Geräteverlust. Wer parallel an Endpoint-Transparenz arbeitet, kann ergänzend EDR sinnvoll einordnen – nicht als Ersatz, sondern als Detektionsebene.

Kompatibilität: nicht jeder Flow ist schon „passkey-native“

Manche Anwendungen unterstützen Passkeys nur als zweiten Faktor oder haben Sonderwege für ältere Clients. Gerade bei VPN-Clients, Terminal-Servern oder Legacy-Webapps ist vorab ein Test mit den realen Geräten wichtig. Wo Passkeys nicht möglich sind, bleibt eine robuste Alternative nötig. Für Konten, die noch Passwörter erfordern, ist ein sauber betriebener Passwortmanager weiterhin Pflicht.

Praxis: Passkeys sicher einführen – Schritte, die funktionieren

Eine erfolgreiche Einführung kombiniert Technik, Prozesse und Nutzerführung. Entscheidend ist, dass Passkeys nicht als „Feature“ ausgerollt werden, sondern als Authentifizierungsstandard mit klaren Betriebsregeln.

Konkrete Umsetzung in wenigen, belastbaren Etappen

• Bestandsaufnahme: Welche Dienste unterstützen Passkeys (WebAuthn) bereits? Welche nutzen SSO/Identity-Provider, welche sind isoliert?
• Priorisieren: Zuerst Admin-Konten, Finanz/HR, E-Mail, Passwort-Reset-Portale und Remote-Zugänge absichern.
• Pilotgruppe: Realistische Nutzergruppe mit verschiedenen Geräten/Browsern auswählen; Sonderfälle (Shared Devices, Schichtbetrieb) bewusst einschließen.
• Geräteanforderungen definieren: Bildschirmsperre, OS-Versionen, Update-Policy, ggf. MDM-Enrollment als Voraussetzung.
• Recovery sauber bauen: Mindestens zwei unabhängige Wiederherstellungswege festlegen (z. B. zweiter Passkey + Recovery-Codes im Tresor).
• Rollout mit Leitplanken: Selbstregistrierung erlauben, aber mit Regeln (z. B. maximal N Passkeys, Benennung, Ablauf bei Gerätewechsel).
• Monitoring: Anmelde- und Registrierungsereignisse loggen, ungewöhnliche Neuregistrierungen prüfen, Helpdesk-Fälle auswerten.

Entscheidungshilfe: Welcher Passkey-Typ passt zum Szenario?

• Wenn Anmeldungen oft an wechselnden PCs erfolgen:
  • Hardware-Key bevorzugen; klarer Besitznachweis, geringer Cloud-Abhängigkeit.
• Wenn Nutzer:innen fast nur mit eigenem Laptop/Smartphone arbeiten:
  • Plattform-Authenticator praktikabel; Komfort hoch, Einführung oft reibungslos.
• Wenn hohe Missbrauchsfolgen bestehen (Admin, kritische Systeme):
  • Hardware-Key plus zweiter, separater Backup-Key; Recovery streng.

Risiken rund um MFA, Push-Fatigue und Session-Schutz

Passkeys sind ein starkes Element, aber sie ersetzen nicht jede Schutzmaßnahme. Gerade Session-Handling und Browser-Sicherheit bleiben relevant.

Warum Push-MFA nicht „phishing-resistent“ ist

Viele MFA-Methoden verbessern den Schutz, sind aber weiterhin angreifbar: Nutzer:innen bestätigen Push-Anfragen aus Gewohnheit, oder Angreifer leiten OTP-Codes in Echtzeit weiter. Passkeys senken dieses Risiko deutlich, weil sie an die Origin gebunden sind. Wo Passkeys noch nicht verfügbar sind, sollten MFA-Verfahren bewusst ausgewählt und hart betrieben werden. Vertiefend hilft MFA sicher nutzen als Orientierung für typische Fehlkonfigurationen.

Session-Diebstahl bleibt ein Thema

Auch mit Passkeys kann ein aktiver Login missbraucht werden, wenn Session-Cookies gestohlen oder Endgeräte kompromittiert sind. Schutz entsteht durch kurze Session-Laufzeiten für sensible Aktionen, Re-Auth für kritische Änderungen, Device-Binding wo möglich und saubere Browser-Härtung. Für Webanwendungen ist außerdem wichtig, Cookie-Attribute korrekt zu setzen und verdächtige Sessions zu erkennen; dazu passt Schutz vor Session-Hijacking.

Fehlerbilder aus dem Alltag und passende Gegenmaßnahmen

In der Praxis tauchen wiederkehrende Muster auf, die sich mit klaren Regeln entschärfen lassen.

„Neuer Passkey registriert“ – legitimer Gerätewechsel oder Angriff?

Ein neues Credential ist nicht automatisch verdächtig, aber immer ein sicherheitsrelevantes Ereignis. Hilfreich sind: Benachrichtigungen an Bestandsgeräte, Freigabeprozesse für Admin-Konten, zeitnahe Logs, und eine Übersicht im Konto, welche Geräte registriert sind. Für besonders schützenswerte Konten gilt: Registrierung neuer Passkeys nur nach frischer Authentifizierung und ggf. zusätzlicher Bestätigung.

Shared Accounts und geteilte Geräte: Passkeys erzwingen klare Verantwortung

Gemeinsam genutzte Konten sind organisatorisch riskant und technisch schwer zu kontrollieren. Passkeys machen das sichtbarer, weil Credentials personenbezogen sind. Besser sind individuelle Konten mit Rollen/Rechten. Wo Shared Devices unvermeidbar sind (Kiosk/Schichtbetrieb), braucht es technische Trennung (separate Profile), kurze Sessions und eine strikte Policy für lokale Entsperrmethoden.

Offboarding: Zugänge entziehen heißt auch Passkeys entfernen

Beim Ausscheiden von Mitarbeitenden müssen nicht nur Passwörter zurückgesetzt, sondern auch registrierte Credentials überprüft werden. Identity-Provider und Dienste sollten zentrale Übersichten bieten, um Passkeys zu widerrufen. Ergänzend ist ein sauberes Geräte-Offboarding entscheidend (MDM-Wipe, Zertifikatsentzug, Token-Revoke).

Passkeys bringen Authentifizierung näher an ein robustes Sicherheitsmodell: kryptographisch, benutzerfreundlich und deutlich resistenter gegen Phishing. Der nachhaltige Effekt entsteht jedoch erst, wenn Recovery, Geräteschutz, Monitoring und Offboarding als gleichwertige Teile des Gesamtsystems betrieben werden.