Anregung: Anmeldung mit Passkey im CCP

    Win98SE4ever


    Ich habe mal eine eine kleine Linkliste für interessierte erstellt:

    @Win98SE4ever - Wenn du interessiert bist, kann ich dir noch Auszüge aus einer Privaten Konversation posten, die etwas tiefer in die Materie geht.


    WebAuthn (1FA oder MFA)?
    WebAuthn ist ein Framework. Dieses kann man den eigenen Anforderungen und Bedürfnissen anpassen. Wenn WebAuthn nur als 1FA (bzw. als 2. Faktor zu etwas anderem) eingesetzt wird, würde man es derart konfigurieren, dass von einem Authenticator "User Presence" verlangt wird. Wenn man hingegen "User Verification" vom Authenticator verlangt, soll dieser einen weiteren Faktor wie Knowledge oder Biometrie gewährleisten, und dann erfüllt ein Passkey ("Passwortlose Anmeldung") eigenständig die Anforderungen an MFA. Die 2FA-Authentifizierungsfaktoren werden hierbei nach NIST SP800-63B durch einen einzelne Authentifizierungstransaktion von einem Multi-Faktor-Authentifikator erbracht. Siehe nebenbei auch den Vergleich User Presence vs User Verification (yubico.com).


    WebAuthn Attestation

    Ein Hardwaremodul wie bspw. das integrierte Trusted Plattform Modul (TPM) wird vom Hersteller mit einem Endorsement Key (EK) - einem Private Key - ausgeliefert. Der öffentliche Schlüssel - der EKPub - wird von einer Zertifizierungsstelle verifiziert. Passkeys die mit Windows Hello geschützt werden, basieren auf der Sicherheit, die das TPM bietet. Deshalb steht hierbei dann eine WebAuthn-TPM-Attestation zur Verfügung (andere Plattformen wie Android haben andere Attestation-Typen), welche vom Serviceprovider auf eine gültige Zertifizierung geprüft werden kann. Dadurch ergibt sich eine geschlossene Vertrauenskette - da sollte ein Authenticator nicht das erforderliche Sicherheitsniveau zum Schutz der Passkeys erfüllen - keine Zertifizierung besteht oder diese ggf. zurückgezogen wird.


    Dies ist die Grundlage dessen, weshalb Passkeys auch Authenticator Assurance Level 3 (AAL3) erfüllen können - nämlich genau dann - wenn der Authenticator für das entsprechende Sicherheitsniveau zertifiziert ist. Es kommt ganz darauf an, welche Zertifizierungsstufe das Hardwaremodul erfüllt und ob diese gültig ist. Die meisten Passkey-Authenticatoren garantieren Authenticator Assurance Level 2 und damit jene Sicherheitsebene, welche für MFA-Szenarien geeignet ist. Es stellt sich damit nicht die Frage, ob ein Anbieter Passkeys unterstützt oder nicht, sondern vielmehr, welche Sicherheitsstufe und Restriktionen für die Passkeys bestehen.


    WebAuthn Attestation Beispiele


    Die technischen Parameter können zum Beispiel auf Yubico demo website getestet werden. Der Authenticator-Response enthält das Attribut `authenticationObject`, welches base64-enkodierte Daten nach RFC 8949 enthält.


    Für KeePassXC enthält dieses folgende Daten ("none" = keine Attestation):


    Code
    {"fmt": "none", "attStmt": {}, "authData": h'...'}

    Während wiederum Windows Hello auf den TPM-Chip zurückgreifen kann und eine entsprechende TPM-Attestation mitsendet:


    Code
    {"fmt": "tpm", "attStmt": {"alg": -65535, "sig": h'....', "ver": "2.0", "x5c": [h'....', h'...], "pubArea": h'...', "certInfo": h'...'}, "authData": h'...'}

    Merke allerdings: Der Passkey kann bei KeePassXC exportiert werden (respektive ist die KDBX-Datei selbst portabel). Ein Passkey der durch den TPM-Chip geschützt wird, ist nicht exportierbar und sollte der TPM-Chip den Zugriff verweigern, ist auch der Passkey nicht mehr zugänglich. Immerhin bürgt der Chip respektive die Attestation für die Sicherheit des PassKeys und des Authenticators.


    WebAuthn Attestation ggf. Overkill

    Derzeit wird davon abgeraten eine WebAuthn-Attestation zu verlangen oder zu validieren. Die offizielle Implementierungsempfehlung ist hierzu, die Attestations bei der Registrierung eines Passkey zu speichern. Sollte man dem Sicherheitsniveau eines Authenticators nicht (mehr) trauen (ergo: Blacklisten), kann man dann auch Nachträglich die entsprechenden Passkeys identifizieren und invalidieren. Dies gehört ganz regulär zur sauberen Implementierung von Passkeys mit dazu! Siehe Attestation (yubico.com). Nach NIST SP800-63B ist es für Authentification Assurance Level 2 (AAL2) (aka: "gewöhnliche MFA-Authentifizierung") nicht erforderlich, die Exportierbarkeit / Synchronisierbarkeit / Transportabilität von in diesem Fall Passkeys zu unterbinden.


    Regulatorische Einordnung

    Das üblicherweise eingesetzte TOTP erfüllt nicht die Anforderungen der DIN EN ISO 9241 Teil 110 (Usability) und ebensowenig wird es die Anforderungen des Barrierefreiheitsstärkungsgesetz, respektive der EU-Richtlinie 2019/882 erfüllen, welche ab 2025 von verschiedenen Einrichtungen und Institutionen eingehalten werden muss. Das Problem an Time-based-One-Time-Passwords ist deren Konzept selbst, dass nur für eine kurze Zeitdauer gültige TOTP-Codes abgetippt werden müssen, welche alle 30 Sekunden wechseln. Dadurch stellt das TOTP unzulässige zeitliche als auch kognitive Anforderungen an den Benutzer, weshalb es verschiedene Regulatorische Anforderungen, wie zum Beispiel die BITV 2.0, nicht erfüllt. Es gibt also nicht nur das umgangssprachliche "Es tut besser und ist angenehmer", sondern auch verbriefte Gründe, die dafür sprechen, alternative Verfahren anzubieten. Bei PassKeys wiederum handelt es sich dann um Implementierungsdetails des Authenticator, welche Faktoren genau und wie geprüft werden (bspw. ob PIN oder Fingerabdruck oder Muster oder Gesichtserkennung oder ...) eingesetzt werden.