Passkeys sind in aller Munde. Aber: Warum sollte mich das interessieren? Mein Passwort ist sicher!

In diesem Post gehe ich darauf ein, wie wir im heutigen Chaos der Authentifikationsmethoden landeten und warum Passkeys eine gute Option für die Zukunft sind.

Wie sind wir hier gelandet?

Das erste Computerpasswort stammt angeblich ¹ vom MIT Compatible Time-Sharing System (CTSS). Dieses System hatte mehrere Benutzerkonsolen, welche keinem spezifischen User zuordenbar waren. Persönliche Daten waren jedoch an den eigenen Account gebunden. Zu dieser Zeit wirkten Passwörter wie die offensichtliche Lösung. Historische Ideen wie Sicherheitsfragen über den Mädchennamen der Mutter wurden auch diskutiert, jedoch aufgrund des höheren Rechenaufwands für etwas so Unwichtiges wie Authentifikation wieder verworfen.

Interessanterweise war dieses System auch das erste Ziel für den Diebstahl von Computerpasswörtern. Mithilfe von Lochkarten konnten User Anfragen für Ausdrucke bestimmter Dateien stellen. Allan Scherr, ein Doktorand am MIT zu dieser Zeit, stellte einen Druckauftrag für die Datei, welche sämtliche Passwörter enthält. Am nächsten Tag fand er einen Ausdruck sämtlicher Passwörter in seiner Ablage.

Diese Geschichte illustriert zwei Sicherheitsprobleme:

1. Wenn es einen Pfad mit schwächerer oder keiner Authentifikation gibt, kann dieser genutzt werden, um den resilienteren Authentifikationspfad zu umgehen. Bei Passkeys bleibt dieses Problem bestehen. Erschienene Artikel über “gehackte” Passkeys haben alternative Loginmethoden genutzt (beispielsweise den SmartTV Login). ² Wer Passkeys einführt, um die Sicherheit zu stärken, muss den ganzen Anmeldeprozess betrachten und nicht nur eine neue Option hinzufügen. Das schwächste Glied einer Kette bricht auch, wenn man ein Starkes daneben setzt.
2. Wenn ein Dritter Zugriff auf die Passwortdatenbank eines Dienstes erhält sind alle Passwörter kompromittiert. Das gilt für alle geteilten Geheimnisse und trifft auch auf unsere heutigen Passwörter zu. Auch wenn es Best Practice ist, Passwörter nicht im Klartext abzulegen, sondern nur in Form gesalzener Prüfsummen, erlaubt das Abgreifen dieser Informationen einen Offline-Angriff mithilfe von Wortlisten oder zufälligem Ausprobieren, um ein gültiges Passwort für die Prüfsumme zu finden. So umgehen Angreifer Limitierungen in der Anzahl der Versuche oder Bandbreitenbeschränkungen über das Internet. Einmal gefunden können Angreifer mit den erlangten Zugangsdaten versuchen, sich bei anderen Systemen anzumelden, wenn der User das Passwort wiederverwendet hat. Dieses Vorgehen nennt sich credential stuffing.

Die MFA Stolperfalle

Wir wissen: Passwörter sind geteilte Geheimnisse, die aufgrund ihrer häufigen Wiederverwendung zu Credential-Stuffing-Angriffen führen können. Das zugrundeliegende psychologische Problem ist allerdings deutlich umfangreicher, denn: User wählen ihr eigenes Passwort.

Die Sicherheit von Passwörtern hängt aus User-Perspektive nur an wenigen Punkten:

1. Passwörter sollen komplex sein

   Passwörter sollten im Idealfall eine große Menge zufällig gewählter Zeichen aus einem möglichst großen Alphabet enthalten (z.B. Ziffern, Buchstaben, Sonderzeichen, …). Das Ergebnis ist ein Passwort, welches schwierig zu erraten, allerdings für die meisten Menschen auch schwer zu merken ist.

2. Passwörter sollen sicher verwahrt werden

   Die Komplexität sorgt dafür, dass Passwörter schwierig zu merken sind. Infolgedessen schreiben viele ihre Passwörter auf. Das klassische Beispiel ist die Haftnotiz am Bildschirm oder unter der Tastatur. Aufschreiben für sich genommen ist nicht problematisch, wenn die Niederschrift sicher aufbewahrt wird. Findet die Ablage an einem durch Andere zugänglichen Ort statt, ist das Problem vergleichbar mit dem Haustürschlüssel unter der Türmatte. Werden komplexe Passwörter vergessen, werden Loginvorgänge in der Praxis häufig über die Passwort vergessen? Funktion durchgeführt, ohne mit der eigentlichen Authentifikationsmethode zu interagieren. Vergleichbar ist diese Art des Einloggens mit den sogenannten Magic Links. Zudem kann in vielen Szenarien Supportpersonal davon überzeugt werden, die zu dem Account gehörige E-Mail-Adresse anzupassen. Anschließend kann der Angreifer sich über den Passwortreset einloggen.

3. Passwörter sollen nur auf der korrekten Seiten eingegeben werden

   Phishing ist eine der ältesten und erfolgreichsten Methoden, um Organisationen und Nutzerkonten im Allgemeinen zu kompromittieren. Wissenschaftliche Studien legen nahe, dass Awareness-Kampagnen nur einen sehr geringen Nutzen für das Problem haben. ³ Das zentrale Problem ist, sobald ein User glaubt auf der korrekten Seite zu sein, wird dieser seine Zugangsdaten mit hoher Wahrscheinlichkeit auch eingeben. Kleinere Tippfehler in URLs und ähnlich aussehende, punycode-Domains machen die Differenzierung schwierig. Als Beispiel sind jrtberlin.de und jrtbеrlin.de, abhängig von der Schriftart, nicht unterscheidbar. Die zweite Domain enthält das kyrillische kleine е anstelle des lateinischen e.

   Verstärkt wird das Problem durch die Fülle an legitimen Domains. Eine Freundin von mir (@ljrk@todon.eu) hat Studierende in einer Vorlesung aus einer Liste an Domains raten lassen, welche der Aufgeführten tatsächlich von Microsoft stammt. ⁴

   So klingen sharepont.online.com, office.m365.com und sharepointonline.com zwar plausibel, entsprechen aber nicht offiziellen Domains, während sich fragwürdig Anhörende wie microsoftrewards.com legitim sind.

4. Passwörter sollten einzigartig sein

   Gerade aufgrund der vorherigen Punkte scheitern viele an diesem Punkt und wählen für alle Dienste ihr Passwort bei denen die Passwortrichtlinie den Einsatz erlaubt.

Zwischenfazit: Passwörter sind ein Konzept, welche an dem grundlegenden Sicherheitsprinzip der psychologischen Akzeptanz von Saltzer und Schroeder scheitert, wenn es sich um ein kryptographisch Gutes handelt. ^{5 6}

Aufgrund der zuvor genannten Probleme mit Passwörtern verlangen Compliance-Richtlinien, Sicherheitspersonal und regulatorische Anforderungen oft den Einsatz eines zweiten Faktors (2FA), welcher heute oft auch als Multi-Faktor Authentifikation (MFA) bezeichnet wird. MFA Methoden sind eine Ergänzung einer konzeptionell kaputten Authentifkationsmethode, welche die Anmeldung Nutzenden erschwert und gleichzeitig nur wenige der eigentlichen Probleme adressiert. Überzeugt ein Angreifer einen User der Phishingseite zu trauen, wird der User nach der Passworteingabe auch den zeitbasierten zweiten Faktor (TOTP) eingeben, die angezeigte Nummer in der Authenticator App anklicken oder die Anmeldung per Knopfdruck bestätigen.

Die meisten Phishing-Werkzeuge können die Anfrage des zweiten Faktors in Echtzeit weiterleiten.⁷ Ein weiterer Faktor versucht meistens ein Problem zu lösen: credential stuffing. Dies gelingt, da es das Geheimnis des Users in Kombination mit einem echt-einzigartigem, maschinell generierten Einmalcode eine nicht wiederverwendbare Authentifikationsmethode ist. Aufgrund dieses Umstands ist die Anforderung MFA einzuführen so populär, da die Einzigartigkeit des Passworts nicht technisch erzwingbar ist, anders als der Einsatz von MFA.

📝 Hinweis

Sind bereits einzigartige Passwörter im Einsatz ist der Sicherheitsgewinn durch TOTP und vergleichbare MFA Methoden gering. Des Weiteren ist der Verlust an Sicherheit durch die Ablage des TOTP-Geheimnisses neben dem Passwort im Passwortmanager minimal, vorausgesetzt es handelt sich nicht um einen gezielten Angriff auf eine Einzelperson, da Credential Stuffing immer noch effektiv verhindert wird. – Das phishen des TOTP funktioniert unabhängig von dem Speicherplatz des TOTP-Geheimnisses.

Bestätigungsanfragen über die Mobiltelefonbenachrichtigungen werden in der Praxis mithilfe einer Social Engineering Taktik umgangen, bei der versucht wird sich mit den erbeuteten Zugangsdaten einzuloggen und eine Vielzahl von Bestätigungsanfragen an den User zu erzeugen. Bestätigt der User die Benachrichtigung nicht, versucht es der Angreifer wiederholt. Bei einer großen Menge an Bestätigungsanfragen kann es passieren, dass ein User sich versehentlich verklickt oder einmalig bestätigt in der Hoffnung, dass der Spam endet. Diese psychologische Schwäche ist bekannt als mfa fatigue.

Eine MFA Methode, welche immer häufiger eingesetzt wird sind Magic Links: Versucht sich ein User einzuloggen erhält dieser eine E-Mail mit einem Link. Ein Anklicken des Links authentifiziert die Sitzung. Werden Magic Links korrekt eingesetzt können diese das Risiko von Phishing effektiv reduzieren. Bei dem Einsatz ist besonders zu beachten, dass die versendeten Links nicht eine entfernte Sitzung authentifizieren, sondern ausschließlich das Gerät auf dem der Link geöffnet wurde. Andernfalls würde ein Angreifer authentifiziert werden, wenn ein User auf den Link klickt. Da sich dieser typischerweise beim Phishen in einem Anmeldeprozess befindet, ist das Klicken des Links aus Sicht des Users legitim. In den letzten Jahren haben immer mehr Seiten diese Methode eingeführt und teilweise die Passwortanmeldung durch Magic Links vollständig ersetzt. Auch wenn es sich hier um eine Verbesserung in Bezug auf die Security handelt, gibt es einige Probleme:

• Die UX bricht, wenn ein User sich am Desktop anmelden möchte, aber den Link auf dem Mobiltelefon öffnet, da der Browser auf dem Smartphone authentifiziert wird anstelle in der Desktopsitzung.
• Das Risiko des Phishings ist reduziert, aber nicht verhindert: Die Magic Links können in ein durch den Angreifer kontrolliertes Formularfeld kopiert werden. Dadurch wird zwar der gewohnte Arbeitsablauf gebrochen und die Wahrscheinlichkeit des Erfolgs reduziert, jedoch nicht ausgeschlossen.
• User sind möglicherweise frustriert von E-Mails, die nach Ablauf des Links zugestellt werden oder gar nicht ankommen.
• Die Security des Loginverfahrens hängt nun am Login des E-Mail-Accounts. Je nach Anbieter kann es sich hierbei um eine Verbesserung oder Reduktion der Sicherheit handeln. Betrachten wir ebenfalls Passwortreset Funktionalitäten war das vermutlich aber bereits der Fall.

Das Ergebnis der meisten MFA Methoden ist eine komplexe Authentifikation, die die Akzeptanz von Usern reduziert. Zudem kann ein überkomplexes MFA Verfahren User dazu ermutigen ein schwächeres, leichter zu merkendes Passwort zu wählen in blindem Verlassen auf die MFA Methode.

Passwortmanager

Neben MFA sind Passwortmanager oft eines der Argumente, warum das Passwort kein überholtes Konzept ist. Auf einer konzeptionellen Ebene versuchen Passwortmanager viele der Probleme von Passwörtern auszugleichen, wie das Merken von Passwörtern und das Generieren von komplexen und zufälligen Passwörtern mit Generatoren, welche zugleich den Richtlinien der Seite entsprechen. Umfragen ergeben, dass nur 36 % der US-Amerikaner einen Passwortmanager nutzen ⁸. Die Anzahl der User, die den integrierten Generator nutzen dürfte noch geringer ausfallen. 23 % der von Forbes befragten gab außerdem, an das gleiche Passwort für 3-4 verschiedene Accounts zu verwenden⁹.

Schauen wir auf das klassische Risikomanagement (ISO 27001) können wir eine von 4 Strategien auf die von uns identifizierten Risiken anwenden: akzeptieren, transferieren, reduzieren oder vermeiden. Aus einer technischen Perspektive interessieren wir uns primär für die Reduktion von Risiken, sowie die Vermeidung von Risiken bspw. durch das Design eines Systems, welche inhärent nicht mit dem Risiko behaftet ist.

Passwortmanager sind nicht in der Lage die meisten Risiken mit Passwörtern zu vermeiden, da sie darauf angewiesen sind durch den User korrekt verwendet zu werden, beispielsweise durch Verwenden des integrierten Passwortgenerators und der Autofill-Funktion, um sicherzustellen, dass die Zugangsdaten auf der korrekten Seite eingegeben werden.

Autofill ist in der Theorie eine gute Idee, da die Funktion versucht eine Loginmaske zu identifizieren und diese mit Zugangsdaten zu befüllen. Funktioniert die Autofill-Funktion wie gedacht, befüllt diese die Loginmaske ausschließlich mit den Zugangsdaten der jeweiligen Seite. Da viele Webseiten sich versuchen durch besonders ausgefallenes Design zu differenzieren, zum Beispiel durch nicht-Standard Formularfelder, sind Passwortmanager nicht immer in der Lage die Loginmaske korrekt zu identifizieren. Dadurch sind User oftmals gezwungen die Felder manuell zu befüllen. Schlimmer noch: Einige Seiten verhindern das Einfügen von Passwörtern in das Passwortfeld.

Diese Brüchigkeit des Verfahrens gewöhnt User daran regelmäßig ihre Zugangsdaten händisch in Felder zu befüllen. Daraus folgt, dass ein nicht-automatisches Befüllen der Phishing-Seite nicht den Loginfluss bricht, sondern den User dazu bewegt das bereits Antrainierte manuelle Befüllen der Felder vorzunehmen. Eine standardisierte Schnittstelle für die Registrierung und den Login ist somit eines der Kernbausteine von Passkeys.

Eine durch die Passwortmanager gut gelöste Thematik ist die sichere Ablage von Geheimnissen. Daher können einige Passkeys auch in Passwortmanagern verwaltet und abgelegt werden.

Wie lösen Passkeys die Probleme?

Das Design von Passkeys geht davon aus, dass es sich bei den meisten Problemen nicht um psychologische bzw. sozio-technische handelt, sondern ausschließlich um technische. Diese technischen Probleme lassen sich durch das Design eines Systems, welches menschliche Schwächen miteinbezieht, lösen. Erhöhte technische Komplexität wird akzeptiert, wenn diese die Komplexität aus User-Perspektive reduziert.

Passkeys adressieren das Problem der geteilten Geheimnisse mit einem sogenannten challenge-response Verfahren, basierend auf public-key Kryptographie.

📝 Hinweis

Public-key-Kryptographie (asymmetrische Kryptographie) basiert auf einem mathematisch verknüpften Schlüsselpaar: dem öffentlichen Schlüssel und dem privaten Schlüssel. Während der öffentliche Schlüssel frei geteilt und einer Identität zugeordnet wird, bleibt der private Schlüssel streng geheim. Für Passkeys ist das Konzept der digitalen Signatur entscheidend: Mit dem privaten Schlüssel wird eine mathematische Operation auf eine Nachricht angewendet, um einen einzigartigen kryptographischen Beweis zu erzeugen. Jede andere Partei kann diesen Beweis anschließend mit dem dazugehörigen öffentlichen Schlüssel prüfen. Ist die Prüfung erfolgreich, steht fest, dass der Beweis von der Person erbracht wurde, die Zugriff auf den privaten Schlüssel hat – ohne dass der geheime Schlüssel jemals offengelegt oder übertragen werden musste.

Passkeys verwenden diese Methodik, um Challenges der Webseite zu signieren. Die Seite kann die Signatur anhand des öffentlichen Schlüssels prüfen und kann so sicherstellen, dass die Anfrage durch den Passkey des Users kommt.

Daraus folgt auch, dass bei einer Kompromittierung einer Webseite, zumindest in der Theorie, der Passkey nicht ausgetauscht werden muss, da der Angreifer die schützenswerte Information für die Authentifikation nicht entwendet haben kann.

---
title: Passkey Schüsselablage
---
flowchart LR
    PW(Passkey Erzeugung) -->|öffentlicher Schlüssel| Server[("Webseite
    (relying party)")]
    PW  -->|privater Schlüssel| Authenticator[("Authenticator
    (bspw. Gerät des Users)")]

Vergleichen wir nun die Anforderungen an Passwörter von oben mit Passkeys:

1. Passwörter sollen komplex sein

   Passkeys basieren immer auf einem einzigartigen privaten Schlüssel, welcher nicht durch den User generiert wird.

2. Passwörter sollten sicher verwahrt werden

   Passkeys werden erstellt, gespeichert und aktualisiert von dem Passwortmanager, Betriebssystem-Schlüsselbund oder physischem Gerät.

3. Passwörter sollen nur auf der korrekten Seiten eingegeben werden

   Passkeys sind nur gültig für die relying-party id (rp.id: Passkey Sprache für den Domainnamen oder die Anwendung) die sie erzeugen hat lassen. Eine Webseite, die durch einen Angreifer kontrolliert wird kann keine Authentifikation für eine andere Seite anfragen.

4. Passwörter sollten einzigartig sein

   Eine relying-party (bspw. eine Webseite) kann mehrere Passkeys registrieren, aber ein Passkey kann nicht zwischen Seiten geteilt werden.

In der Praxis sieht die Verwendung von Passkeys so aus, dass der User durch das Betriebssystem oder den Webbrowser aufgefordert wird eine Identität aus dem Passwortmanager, betriebssystemeigenen Schlüsselbund oder einem externen Gerät auszuwählen und ggf. den Zugriff mithilfe der Gerätezugangsdaten z.B. einem Fingerabdruck oder einem Geräte-PIN zu bestätigen:

Eine technischere Erklärung wie die Komponenten von Passkeys zusammenspielen findet sich im Anhang unten.

FAQ

Was ist ein Passkey?

Ein Passkey ist ein Marketing Begriff für ein FIDO2 resident-key credential mit user-verification.

Sind Passkeys ein Vendor-Lockin?

Kurz: Nein, Passkeys sind ein offener Standard.

In der Vergangenheit haben Seiten wie Google, Apple, Facebook, usw. versucht die Authentifikation dritter Seiten an sich zu binden mithilfe von “Einloggen mit …” Optionen. Passkeys sind ein universeller Standard. Mit der neuen Credential Exchange Specification (CX)¹¹ gibt es eine Option die Zugangsdaten sicher zwischen Anbietern zu migrieren.

Allerdings sollte erwähnt werden, dass Anbieter den Einsatz von FIDO2 und damit auch Passkeys beschränken können:

• Beschränkung auf einen spezifischen Authenticator mithilfe der AAGID ¹²: Praktisch in Organisationen in denen man die Nutzung auf offiziell herausgegebene Mittel der IT-Abteilung beschränken möchte oder auf jene, die eine bestimmte Zertifizierung besitzen.
• Beschränkung auf Geräte gebundene device-bound Passkeys (exkludiert Software basierte, synchronisierbare Passkeys bspw. in Passwortmanager abgelegten statt dem TPM oder einem USB Token)

Ein Negativbeispiel für den Privatgebrauch ist Apples Beschränkung auf iOS-Geräte. Eine Anmeldung mit FIDO2 USB Tokens ist hier nur als zweiter Faktor nach der Passwort-Authentifikation möglich.

Kann ich weiterhin meinen USB Token benutzen?

Ja, FIDO2 USB Token, welche resident keys unterstützen, sind und werden weiterhin unterstützt. Die primäre Änderung mit FIDO2 ist, dass das Ökosystem nicht mehr beschränkt ist auf Hardware-basierte Schlüsselverwaltung. Für die Meisten dürfte der Einsatz von Passkeys eine Verbesserung hinsichtlich der Benutzbarkeit und Security verglichen mit Passwort und MFA darstellen. Personen mit besonderem Gefährdungsmodell sollten weiterhin FIDO2 USB Tokens benutzen oder Hardware-basierte Passkeys, die nicht übertragbar und mit einer starken PIN geschützt sind.

Sollte ich einen Hardware-Token benutzen?

Es kommt darauf an. Wir müssen differenzieren zwischen besonders risikobehafteten Anwendern, wie beispielsweise Personen die in der Öffentlichkeit stehen oder besonders hoch privilegierte User in einer Organisation wie beispielsweise Administratoren und Mitarbeitende mit Zugang zu besonders schützenswerten Daten wie bspw. HR.

Ein USB Hardware-Token ist eine besondere Form des device-bound Passkeys, da es sich um einen sogenannten roaming authenticator handelt. Roaming deshalb, weil sich dieser zwischen verschiedenen Plattformen hin und her bewegen kann und nicht an die Platform gebunden ist. Eine Secure Enclave beispielsweise kann ein platform authenticator sein, da diese ein Bestandteil der Plattform ist.

Da Hardware Token aufwändiger in der Nutzung sind, können diese zum Beispiel für den Schutz des Passwortmanagers verwendet werden, der synchronisierbare Passkeys enthält.

Mangelhafte Plattformunterstützung

Dieser Punkt war anfangs einer der Kernprobleme, wird aber zunehmend irrelevant. Aktuelle Versionen von Android, iOS, macOS, Windows und ChromeOS unterstützen FIDO2.

Desktop Linux hinkt etwas hinterher. Hier werden seit langem USB Security Tokens und Bluetooth Authenticators (z.B. über Chromium basierte Browsers) unterstützt und Passwortmanager über entsprechende Browsererweiterungen. Eine generische Schnittstelle auf Betriebssystemebene mit einer Option Passkeys auf dem Gerät mithilfe des TPM2 zu speichern ist in Arbeit. Siehe: linux-credentials project ¹³

Passkeys können nicht geteilt werden

Das geteilte Netflix-Passwort kennt jeder und es ist ein häufiges Missverständnis, dass Passkeys das Teilen von Accounts unterbinden.

Viele Seiten erlauben zum einen mehrere Passkeys zu registrieren, zum anderen gibt es Passwortmanager, wie Apple Passwörter, die ein temporäres Teilen von Passkeys erlauben. Ein roaming authenticator, wie z.B. ein YubiKey, kann anderen in die Hand gedrückt werden wie ein Haustürschlüssel.

Passkeys ermöglichen BigTech den Zugriff auf biometrische Merkmale

Nein, Biometrie wird lokal genutzt zur Entsperrung des Authenticators, vergleichbar mit der PIN einer SIM im Telefon. Die Nutzung von Biometrie ist optional und fällt zurück auf andere Gerätezugangsdaten wie eine PIN oder ein Passwort.

Zudem kann Biometrie in einigen Situationen für bestimmte Personengruppen die Sicherheit erhöhen: Wird ein Telefon im öffentlichen Nahverkehr entsperrt kann ein Dritter nicht die Eingabe der Zugangsdaten anschauen für ein späteres entfernen der Aktivierungssperre des Diebesguts. Daher kann Biometrie die Wahrscheinlichkeit eines Gerätediebstahls reduzieren.

Ermittlungsbehörden dürfen in einigen Ländern Personen zwingen das Gerät mit Biometrie zu entsperren, aber nicht ein Passwort herauszugeben. Abhängig vom persönlichen Threat-Model sollte jeder individuell die Entscheidung treffen ob Biometrie eine Option darstellt. (Relevant hierfür ist noch der Aspekt, dass sowohl bei Android¹⁴ als auch iOS¹⁵ die Möglichkeit mit Biometrie zu entsperren kurzfristig deaktiviert werden kann.)

Passkeys erschweren Digitales Erbe und Accountzugriffe nach dem Tod

Werden Passwörter nach gängigen Best Practices angewendet sollten sich die Probleme wenig bis gar nicht unterscheiden. Passkeys werden bei den Meisten im Passwortmanager abgelegt, welcher mit den Gerätezugangsdaten geschützt ist. Gerätezugangsdaten sind Angehörigen meistens bekannt oder können über Cloudzugänge ggf. zurückgesetzt werden. In einigen Ländern können Clouddienste Gerätehersteller gezwungen werden Zugriff zu gewähren unter Vorlage einer Sterbeurkunde.

Einige Seiten, wie z.B. Google erlauben zu Lebzeiten die Definition eines digitalen Nachlasses und automatischem Zugriff auf Accountdaten.¹⁶

Anhang

Was sind die Komponenten von Passkeys?

Aus welchen Komponenten bestehen Passkeys? Um die Funktionsweise von Passkeys grundlegend zu verstehen, können wir das folgende Diagramm betrachten:

---
title: Passkey Komponenten
---
flowchart LR
	Authenticator("
	Authenticator
Credential Storage
(z.B. USB Token, Passwortmanager,...)") <-->|CTAP2| Client("Client
Normalerweise Browser/OS")
    Client <-->|WebAuthn| RP("Relying Party (RP)
Webdienst")

Es gibt einen Authenticator, dieser kann eine Secure Enclave in einem Smartphone, ein TPM2 Chip in einem Laptop, ein Passwortmanager oder ein FIDO2 USB Token (wie bspw. ein YubiKey) sein. Auf diesem wird der private Schlüssel gespeichert. Ein roaming authenticator ist ein Authenticator, welcher nicht in eine Plattform integriert ist (wie ein TPM2 oder eine Secure Enclave). Der Authenticator kommuniziert mit dem Browser oder Betriebssystem des Users (client) über das Client to Authenticator Protocol 2 (CTAP2). Das CTAP2 standardisiert die Integration eines externen Authenticators in eine Plattform über eine Transportmethode wie z.B. USB, NFC or Bluetooth. Versucht ein User sich gegenüber einer relying party, beispielsweise einer Webseite, zu authentifizieren findet die Kommunikation über ein Protokoll mit dem Namen Webauthn statt. Dieser Vorgang heißt ceremony.

Es gibt 2 Arten von webauthn Credentials: resident key (rk) und non-resident key (nrk). Resident key meint die Eigenschaft, dass der private Schlüssel des webauthn credential auf dem Authenticator gespeichert wird. Non-resident keys sind flüchtig und der private Schlüssel wird im Bedarfsfall deterministisch aus der Credential-ID, welche von der relying party herausgegeben wird, neu abgeleitet. Daraus folgt eine Auswirkung auf die UX: Ein non-resident key hängt davon ab, dass die relying party die Credential-ID herausgibt. Die Seite kann jedoch nur die dem User zugehörige Credential-ID herausgeben, wenn die Seite weiß welcher User sich zu authentifizieren versucht. Daher muss bei non-resident keys der User einen identifizierenden Faktor wie beispielsweise einen Nutzernamen oder eine E-Mail-Adresse angeben bevor das Credential verwendet werden kann für die Authentifikation. Diese Art wird daher oft als zweiter Faktor für Passwortsysteme verwendet.

Ein resident key ist ein vollständiger privater Schlüssel, welcher auf dem Authenticator gespeichert wird inklusive der relying-party un einem Identifier für den Account. Dieser Typ kann daher verwendet werden ohne, dass der User irgendetwas in ein Formularfeld eintragen muss. Aus Nutzerperspektive sieht das in der Praxis so aus, dass nach einem Klick auf Login eine Abfrage des Gerätes oder des Browsers erscheint, welche den User dazu auffordert ein Credential auszuwählen und dieses ggf. mit Geräte-PIN oder Biometrie zu bestätigen. Diese user-verification (uv) ist optional, aber im Regelfall eine Voraussetzung für den Begriff Passkey. Zusätzlich gibt es das etwas schwächere Konzept der user-presence (up), welche die Anwesenheit einer Person am Authenticator verifiziert. Dies wird meistens über das Berühren eines USB Tokens realisiert. Biometrische user-verification impliziert meistens eine user-presence zusätzlich zur user-verification.

Die Eingebaute user-verification des Authenticators ist der Grund warum Passkeys oft als MFA klassifiziert werden, unabhängig von der Fragestellung, ob man aus Security Perspektive von einer MFA sprechen kann. Diese Diskussion führt in diesem Blogpost allerdings zu weit und ist eventuell ein Thema für ein anderes Mal.