Wie überhitzter Passkey-Hype Sicherheitsschlüssel nutzlos macht

• Wenn sich Abläufe verbreiten, die Passkeys als resident key definieren und verlangen, stoßen Sicherheitsschlüssel wie Yubikey, Feitian oder Nitrokey wegen ihres begrenzten Speicherplatzes schnell an Grenzen
• Bei non-resident credentials entschlüsselt der Sicherheitsschlüssel die von der Relying Party bereitgestellte Credential ID, um den privaten Schlüssel für die jeweilige RP zu erhalten; im Gerät selbst wird nur ein Master Key gespeichert
• Im Gegensatz dazu speichern resident/discoverable credentials den privaten Schlüssel selbst auf dem Sicherheitsschlüssel und belegen damit pro Konto einen Slot; Nitrokey unterstützt 8, Yubikey meist nur etwa 20 bis 32
• Sicherheitsschlüssel mit CTAP2.0 können resident keys nicht einzeln löschen, sondern müssen vollständig zurückgesetzt werden; dabei ändert sich auch der Master Key, sodass auch bestehende non-resident keys nicht mehr funktionieren
• Wenn Dienste und Bibliotheken resident keys standardmäßig verlangen, müssen Nutzer mit mehr als 150 Konten mehrere Sicherheitsschlüssel und Backup-Schlüssel verwalten, wodurch es schwer wird, den gewünschten Authenticator frei zu wählen

---

Warum resident keys im Zentrum des Problems stehen

• Der Kern der Sorge, dass die überhitzten Erwartungen an Passkeys Sicherheitsschlüssel wie veraltete Geräte wirken lassen könnten, liegt bei resident keys
• Die Vorstellung, Sicherheitsschlüssel könnten eine „unbegrenzte“ Zahl von Konten unterstützen, beruht in vielen Fällen auf dem Verfahren der non-resident credentials
• Resident keys verbrauchen tatsächlich internen Speicher des Sicherheitsschlüssels; mit wachsender Kontenzahl werden die Grenzen des Geräts daher unmittelbar sichtbar

Funktionsweise von non-resident credentials

• Bei non-resident credentials übermittelt die Relying Party bei der Authentifizierung die credential ID über den Browser an den Sicherheitsschlüssel
• Die credential ID ist ein verschlüsselter Blob, den nur der Sicherheitsschlüssel entschlüsseln kann; das Ergebnis der Entschlüsselung ist der private Schlüssel speziell für diese Relying Party
• Der Sicherheitsschlüssel signiert die Challenge mit dem entschlüsselten privaten Schlüssel und gibt die Signatur an Browser und Relying Party zurück
• In dieser Struktur befindet sich der private Schlüssel nicht dauerhaft in der sicheren Enclave; im Sicherheitsschlüssel selbst liegt nur der master key
• Die credential ID wird mit AES-128 verschlüsselt und mit einem HMAC versehen, sodass sie nach Einschätzung schwer von außen zu manipulieren oder zu entschlüsseln ist
  • Der Vergleich lautet: Wenn AES-128 gebrochen würde und man private Schlüssel ohne Sicherheitsschlüssel entschlüsseln könnte, wären auch TLS-Verschlüsselung oder SSH angreifbar

Unterschied zu resident/discoverable credentials

• Bei einem resident key oder discoverable credential wird der private Schlüssel im Sicherheitsschlüssel gespeichert
• Wenn die Relying Party eine leere Liste von credential IDs sendet, findet der Sicherheitsschlüssel die für diese RP nutzbaren Schlüssel, wählt einen aus und signiert damit
• Diese Struktur ist nicht darauf angewiesen, von außen eine credential ID zu erhalten und sie mit dem master key zu entschlüsseln
• Stattdessen belegt jedes Credential internen Speicher im Sicherheitsschlüssel, sodass die Zahl der resident-key-Slots zur praktischen Begrenzung der Kontenzahl wird

userVerification ist unabhängig von resident keys

• Es gibt die Verwechslung, dass ein Credential zwingend resident sein müsse, um userVerification zu erzwingen; die beiden Konzepte sind jedoch getrennt
• Ein Sicherheitsschlüssel kann nicht nur per Berührung Presence bestätigen, sondern intern per PIN oder Biometrie prüfen, ob es sich um den tatsächlichen Nutzer handelt
• Dieses Verhalten wird über das userVerification flag gesteuert und funktioniert unabhängig von key residency
• Daher kann ein Gerät auch ohne resident key eigenständig wie ein Multi-Faktor-Authenticator verwendet werden

Speicherplatz von Sicherheitsschlüsseln und CTAP-Einschränkungen

• Da resident keys im Gerät gespeichert werden, ist die Zahl der Slots eines Sicherheitsschlüssels wichtig
  • Nitrokey unterstützt 8 resident keys
  • Yubikey unterstützt in der Regel 20 bis 32
  • Einige Schlüssel unterstützen resident keys überhaupt nicht
• Auch der vom Sicherheitsschlüssel implementierte CTAP-Standard beeinflusst die Verwaltbarkeit stark
  • CTAP2.1 und CTAP2.1PRE können resident keys einzeln verwalten, aktualisieren und löschen
  • Bei CTAP2.0 ist zum Löschen eines resident key ein vollständiges Zurücksetzen des Geräts erforderlich
• Beim Zurücksetzen eines CTAP2.0-Geräts wird auch der master key zurückgesetzt, sodass bestehende non-resident keys ebenfalls nicht mehr funktionieren
• Viele Sicherheitsschlüssel dürften CTAP2.0 sein; bei Yubico hängt die CTAP-Version von der Firmware-Version ab

Der Name Passkeys und die Verbreitung der resident-key-Definition

• Apple kündigte 2022 in macOS/iOS die Funktion passkeys an, die Touch ID und Face ID wie einen WebAuthn authenticator nutzt
• Der Name passkeys gilt als nutzerfreundlicher als „webauthn authenticator“ oder „security key“
• Danach entstanden verschiedene Auslegungen, ohne dass die Bedeutung von passkeys eindeutig festgelegt war
  • Die Rust-WebAuthn-Bibliothek und Implementierer von Relying Parties definierten passkeys als Bezeichnung für alle Authenticatoren, die Nutzer auswählen können
  • Einige Community-Mitglieder bezeichneten passkeys als Credentials, die zwischen mehreren Geräten synchronisiert werden
  • Auf der FIDO-Authenticate-Konferenz erschien die Definition „passkey ist ein resident key“, und später verwendete auch FIDO diese Definition in den FAQ
• Ein Grund, warum die resident-key-Definition Aufmerksamkeit erhält, ist ihre Verbindung zur geplanten Browser-Funktion conditional UI
  • Wenn ein Credential ein resident key ist, lassen sich Benutzername und WebAuthn-Credential automatisch vervollständigen
  • So entsteht eine Nutzererfahrung, bei der der Benutzername nicht manuell eingegeben werden muss

Nutzerprobleme durch die Pflicht zu resident keys

• Wenn WebAuthn-Bibliotheken dazu anleiten, bei jeder Registrierung resident keys zu verlangen, können Sicherheitsschlüssel mit begrenztem Speicherplatz schnell voll werden
• Hat man zum Beispiel mehr als 150 gespeicherte Passwörter in einem Passwortmanager, wären mindestens 5 Yubikeys nötig, um sie alle in resident keys umzuwandeln
• Rechnet man Backups ein, könnten 10 bis 15 Yubikeys zu verwalten sein
• Das ist eine schlechte Nutzererfahrung für Menschen, die sich für Sicherheitsschlüssel entschieden haben, und die resident-key-Pflicht bei Passkeys kann die Nutzung von Sicherheitsschlüsseln selbst erschweren
• Im Marketing für FIDO-zertifizierte Schlüssel werden Formulierungen wie „unbegrenzter Key-Pair-Speicher“ oder „keine Begrenzung der Zahl registrierter Konten“ verwendet; für non-resident keys stimmt das zwar, steht aber im Konflikt mit einer resident-key-Pflicht
• Eines der Ziele der WebAuthn Work Group ist, dass Nutzer den gewünschten Authenticator ohne Nachteile frei wählen können; eine erzwungene Nutzung von resident keys passt jedoch nicht zu diesem Ziel
• Als Authenticator-Typen, die in einer Passkey-Umgebung korrekt funktionieren, werden Apple passkeys, Android passkeys, Passwortmanager mit WebAuthn-Unterstützung, Windows mit TPM 2.0 sowie Chromium-basierte Browser auf macOS genannt, die Touch ID wie ein TPM verwenden

Mögliche Gegenmaßnahmen

• Eine Möglichkeit wäre, das Verhalten von rk=preferred so zu ändern, dass auf Sicherheitsschlüsseln keine resident keys erzeugt werden
  • Derzeit kann eine Relying Party die gewünschte Stufe für resident keys als discouraged, preferred oder required angeben
  • Aktuell erzeugt rk=preferred auch auf einem Roaming Authenticator wie Yubikey einen resident key und verhält sich dadurch letztlich ähnlich wie rk=required
  • Würde man preferred zu „resident key nur erzeugen, wenn der Speicherplatz unbegrenzt ist“ abschwächen, könnten Android/iOS resident keys erstellen, ohne den Speicherplatz von Sicherheitsschlüsseln zu verbrauchen
  • Die WebAuthn WG steht dieser Änderung bislang ablehnend gegenüber; wenn Browser sie separat implementieren sollen, hängt es realistisch gesehen von der Entscheidung des Chrome-Teams ab
• Eine weitere Möglichkeit wäre, von Passkey-Bibliotheken die Nutzung von rk=discouraged zu verlangen
  • rk=required kann Sicherheitsschlüssel ausschließen
  • rk=discouraged kann dazu führen, dass Android-Nutzer keine conditional UI erhalten
  • Da es für Benutzernamen bereits Autovervollständigung gibt, wird dies als besser eingeschätzt, als Sicherheitsschlüssel auszuschließen
• Man könnte FIDO auch auffordern, Speicherplatz für resident keys als Zertifizierungsmerkmal zu verlangen
  • Derzeit schreibt FIDO für zertifizierte Geräte keine Speicherplatzanforderungen vor
  • Wenn FIDO resident keys will, sollten zertifizierte Geräte tausende resident keys speichern können, so die Forderung

Fazit

• Der überhitzte Trend, Passkeys als resident keys zu verstehen, kann Nutzer von Sicherheitsschlüsseln daran hindern oder es ihnen massiv erschweren, online den gewünschten Authenticator zu wählen
• Das Problem liegt weniger bei Passkeys selbst als darin, resident-key-Anforderungen pauschal auf Sicherheitsschlüssel mit begrenztem Speicherplatz und begrenzten Verwaltungsfunktionen anzuwenden

[GN⁺]

Hacker-News-Kommentare

• Das ist zwar etwas anderes als Kryptografie an sich, aber meine Mutter rief mich völlig panisch an, weil sie nicht mehr in Gmail kam. Wie sich herausstellte, hatte Google ihr neues Android-Handy automatisch als Passkey registriert und das zur Standard-Anmeldemethode gemacht, aber die Oberfläche war extrem verwirrend. Zu erwarten, dass man für die Anmeldung mit Passwort die zweite Option anklicken oder verstehen muss, was ein Passkey ist, halte ich für zu viel. Es hieß, man habe „einen Passkey an Android gesendet“, aber auf dem Handy kam keine Benachrichtigung an, und auch nach 30 Minuten war es nicht zu lösen. Den automatisch registrierten Passkey konnte man nicht löschen und den Standard-Authentifizierungsablauf nicht deaktivieren. Googles UX ist furchtbar, und es wirkt wie eine dumme Entscheidung, die angepasste Android-Version eines günstigen Samsung-Handys als Grundlage für ein groß angelegtes Authentifizierungssystem zu vertrauen.

  • Bei Googles Zwei-Faktor-Authentifizierung gibt es dasselbe Problem. Es heißt: „Wir haben eine Benachrichtigung an Ihr S21 gesendet“, aber tatsächlich kommt die Benachrichtigung in einem von drei Fällen gar nicht oder erst nach fünf Minuten an, selbst wenn man das entsperrte S21 in der Hand hält. Das ist nur eines von mehreren Problemen, die ich in letzter Zeit mit Google hatte. Früher wollte ich Google wegen Datenschutz eher so gut es geht meiden, jetzt setze ich alles daran, meine Nutzung von Google so weit wie möglich zu reduzieren. Bei Google Maps wurde mein Unternehmen ohne erkennbaren Grund entfernt, und die erneute Eintragung dauerte zwei Wochen; mit einem Menschen zu sprechen war unmöglich. In jeder Support-E-Mail bekommt man eine Telefonnummer, aber das ist die Nummer des Anzeigen-Supports, der für ein gesperrtes Unternehmenskonto nichts tun kann, und man wollte nicht einmal glauben, dass das Google-Business-Team diese Nummer als Support-Kontakt angibt. Ich musste 30 Minuten lang dieselben Fragen wiederholen, bis mir ein Mitarbeiter des Google-Ads-Supports bestätigte, dass es keine Möglichkeit gibt, mit jemandem für Google Business zu sprechen. Inzwischen bin ich einfach ein Anti-Google-Evangelist geworden.
  • Wegen der unerwünschten Aufforderung „Wir haben eine Benachrichtigung an Ihr Smartphone gesendet“ überlege ich ernsthaft, mein Unternehmen aus dem Google-Ökosystem herauszuziehen. Ich würde es verstehen, wenn ich mich plötzlich von der anderen Seite der Erde aus einlogge oder sonst immer Linux nutze und der Browser plötzlich als Windows erkannt wird. Aber wenn man den auf Privatsphäre ausgerichteten Browser ungoogled chromium verwendet, passiert das bei jeder Authentifizierung, selbst von derselben IP aus. Was, wenn der Akku des Handys leer ist? Was, wenn man das Handy verloren hat und zur Wiederherstellung der Zugangsdaten für die Ortungsdienste einen Passwort-Reset per E-Mail anstoßen muss, sich aber nicht in die E-Mail einloggen kann? Dann beginnt die Prozedur „Fragen beantworten“. Ein versteckter, nicht verantwortlicher Algorithmus stuft ungoogled chromium unter Linux als verdächtig ein, und wenn man die Antwort auf Fragen wie „Wie viel Prozent des aktuell verfügbaren Speicherplatzes nutzen Sie?“ falsch im Kopf hat, ist die Wiederherstellung des Zugriffs Glückssache. Nebenbei: Ich bin zahlender Google-Nutzer.
  • Kleine Korrektur: Ein Passkey wird nicht an Android „übertragen“. Bei der Gmail-Anmeldung scannt man einen im Browser angezeigten QR-Code, um nachzuweisen, dass man den Passkey auf Android besitzt. Den Punkt verstehe ich trotzdem vollkommen. Sowohl UX als auch Begriffe sind verwirrend. Selbst wenn jeder Schritt Erklärungen bietet, hilft das kaum, weil Menschen darauf trainiert sind, kleine Erklärungstexte zu überspringen und den größten, auffälligsten Button zu drücken, besonders wenn es eilig ist. Das ist wirklich ein schwieriges UX-Designproblem.
  • Damit war für mich eine Grenze überschritten. Mir wurde klar, dass Google Entscheidungen nicht aus Nutzersicht trifft. Sie verdienen Geld mit Werbekunden, stellen Dienste nur so weit bereit, dass Nutzer nicht abspringen, und halten sie nur so weit am Leben, dass Wettbewerber abgewehrt werden. Solange Nutzer nicht gehen, kümmert es Google nicht, und es muss sie auch nicht kümmern. Wer etwas anderes will, braucht Dienste, die nicht von Werbekunden bezahlt werden. Wenn Google Nutzer auf die eine Art ausbeutet, beutet Apple sie eben auf eine andere Art aus; sich sein Gift auszusuchen, ist keine echte Option.
  • Fairerweise ist das weniger ein Problem von Passkeys selbst als vielmehr ein dummes Problem der Produkt-UX von Google. Wenn Google die Login-UX plötzlich auf eine Weise ändert, mit der Nutzer nicht vertraut sind, ist Verwirrung bei den meisten unvermeidlich.

• Weil Apple es nicht wirklich definiert hat, haben Denker die Lücke für Nutzer gefüllt, die wissen wollen: „Was ist ein Passkey überhaupt?“ Ich hatte verstanden, dass Apple Passkeys als Schlüsselpaare definiert hat, die über iCloud Keychain synchronisiert werden. Auch in der WWDC-2021-Präsentation wurden Passkeys von Sicherheitsschlüsseln abgegrenzt, weil sie „immer dabei“ sind, also wegen Gerätesynchronisierung, und „wiederherstellbar“ sind. Später scheint die Definition auf andere Cloud-Synchronisierungsverfahren ausgeweitet worden zu sein. Ich finde, dieser Artikel geht einen falschen Kompromiss ein. Sicherheitsschlüssel sind nicht wichtig[1]. Denn sie werden nur von sehr wenigen technischen Nutzern und einer kleinen Zahl von Unternehmen eingesetzt, denen Sicherheit wirklich wichtig ist. Um das Web sicherer zu machen, müssen Menschen von Passwörtern weggebracht werden, und 99 % der Bevölkerung werden keine Sicherheitsschlüssel verwenden, solange sie nicht dazu gezwungen werden. Passkeys haben vor allem dank der tiefen Integration ins Betriebssystem gute Chancen, Passwörter zu ersetzen. Man sollte Authentifizierung nicht auf die weniger als 1 % der Nutzer optimieren, denen die Slots für resident keys ausgehen. [1] Ich besitze 3 YubiKeys, 3 Yubico Security Keys und 1 SoloKey.

  • Das Ziel war nicht das Apple-Passkey-Produkt, sondern eine branchenweite Initiative. Bis zur Einführung 2022 war die Definition lockerer geworden, eher zu einer „Erfahrung“, die zum Beispiel auffindbar ist und Optionen zur Nutzerverifizierung bietet. Nutzer können wählen, ob sie einen Passkey-Anbieter verwenden, der Backup und Wiederherstellung ermöglicht, und die vertrauende Partei erhält dieses Signal. Anhand dieses Signals kann sie auch entscheiden, ob sie vorschlagen sollte, die Passwort-Login-Option zu entfernen.
  • Passkeys werden tatsächlich von der FIDO Alliance definiert. Laut FIDO-Standard ersetzen Passkeys Passwörter und ermöglichen Nutzern, sich auf mehreren Geräten schneller, einfacher und sicherer bei Websites und Apps anzumelden. Anders als Passwörter sind Passkeys immer stark und phishingresistent. https://fidoalliance.org/passkeys/

• Ich verstehe nicht, warum rk=required überhaupt existiert. Es hätte von Anfang an keine Option sein dürfen.
  Genau wegen solcher Dinge war ich gegenüber Passkeys und den daran Beteiligten immer besorgt und skeptisch. Sie tragen die Verantwortung, das Protokoll so zu entwerfen, dass es nicht zu einem praktischen Werkzeug für allerlei bösartige Marktpraktiken wird, mit denen Großkonzerne wie Microsoft Sicherheit und Kompatibilität massiv beschädigen und Wettbewerb abwürgen. Aber die Haltung, die in Texten und Beiträgen immer wieder durchscheint, wirkt eher wie: „Leckt uns, wir machen Missbrauch noch einfacher.“ Das ist nicht nur ein Problem von Resident Keys; zum Beispiel kann auch die Art, wie Attestation gehandhabt wird, leicht dazu missbraucht werden, Unternehmen zu ruinieren.

  • Das Ziel hier scheint zu sein, das Smartphone zum Passkey zu machen und sonst gar nichts mehr zu verwenden. Aus dieser Perspektive ergibt alles im Artikel Sinn.
  • Ich halte das für weniger schlimm als Missbrauch von Attestation.
    Wenn ein Dienst rk=required setzt und die Plattform das nicht aktivieren oder unterstützen will oder kann, dann dürfte der Ablauf immer fehlschlagen, sodass man sich nicht einmal registrieren kann. Wenn das Ziel ist, Nutzer zu onboarden und das Geschäft auszubauen, wirkt das wie ein Eigentor.
  • Ich frage mich, worin genau das Problem besteht, dass „die Art, wie Attestation gehandhabt wird, leicht dazu missbraucht werden kann, Unternehmen zu ruinieren“.

• Ich komme überhaupt nicht aus dem Security- oder Kryptografie-Bereich, deshalb war dieser Artikel für mich sehr schwer nachzuvollziehen, und ich vermute, anderen geht es ähnlich.
  Für Leute mit genug Hintergrundwissen mögen das seltsame Fragen sein, aber ich bleibe alle ein, zwei Sätze hängen. Ich verstehe nicht, wie und warum „am Ende alles auf eines hinausläuft: Resident Keys“, und auch nicht die Verbindung zu Passkeys oder HSMs. Die Aussage, man müsse verstehen, was „discoverable/resident keys“ sind, ist unklar: Bedeutet sie, dass alle Resident Keys discoverable Keys sind, dass alle discoverable Keys Resident Keys sind, oder beides? Wenn es heißt, man habe gesehen, dass die meisten Keys „unbegrenzte“ Konten unterstützen, weiß ich nicht, ob mit Keys Passkeys gemeint sind, in einem HSM gespeicherte Schlüssel oder beides. Und bei „einen mit einem Schlüssel umhüllten Schlüssel an den Security Key senden“ bin ich mir ebenfalls unsicher, ob das heißen soll, dass HSMs deshalb für unbegrenzte Konten geeignet sind, weil man einen Schlüssel mit einem anderen Schlüssel umhüllen und speichern kann.

  • Der Kern scheint zu sein, dass WebAuthn in Richtung eines Passkey-Modells gedrängt wird, bei dem jede Website Credentials erzeugt, die Speicherplatz verbrauchen. Ein anzeigbarer Sitename und Kontoname, ein User-Record-Handle, ein privater Schlüssel und weitere Dinge belegen alle Speicherplatz.
    Ein Smartphone kann problemlos 10.000 Passkeys speichern, aber ein aktueller Hardware-Key kann im verfügbaren Flash womöglich insgesamt nur 25 speichern. Dieser Speicherplatz wird wegen der Discoverability benötigt. Wenn man zum Beispiel auf der GitHub.com-Loginseite die neue Passkey-Unterstützung nutzt, kann man sich anmelden, ohne auch nur den Kontonamen einzugeben. Der Browser bietet eine Erfahrung wie bei einem Passwortmanager, und Passkeys werden lokal zu Einträgen für Website-Konten, ähnlich wie Passwörter in einem Passwortmanager. WebAuthn hat aber auch mehrere Modi, die keine Passkeys sind. Nicht auffindbare Credentials erfordern, dass für ein bestimmtes Nutzerkonto eine Liste von Handles bereitgestellt wird; diese Handles wurden bei der Registrierung vom Key geliefert. Bei der Authentifizierung werden nur Credentials als Optionen angeboten, die zu den Handles passen. Hardware-Security-Keys nutzen das aus, indem sie die für künftige kryptografische Operationen benötigten Datensätze im Handle selbst speichern; dieser Modus verwendet keinen Flash-Speicher. Wenn der Nutzer seinen Nutzernamen eingibt, gibt irgendeine API die Handle-Liste zurück, und diese kann auf den Security Key angewendet werden, um sich ohne Speicherplatzlimit zu authentifizieren. Allerdings verfolgen viele Websites die Policy, die Existenz eines Kontos nicht offenzulegen. Man kennt Wiederherstellungsabläufe wie: „Wenn dieses Konto existiert, erhalten Sie in Kürze eine E-Mail.“ Eine API im Loginprozess, die erkennen lässt, ob es ein Konto zu einem Nutzernamen oder einer E-Mail gibt und wie viele Credentials erfasst wurden, könnte für Websites schwer akzeptabel sein. Am Ende wirkt es wahrscheinlicher, dass Security Keys mit zehnmal mehr Speicher erscheinen, als dass Websites diesen Ablauf breit übernehmen und damit die heutigen Hardwaregrenzen beeinflussen.
  • Ich stimme zu, dass die Argumentation des Artikels nicht gut ist. Der Kern ist die Behauptung, dass die Möglichkeit im WebAuthN-Protokoll, mit der eine Relying Party rk=required angeben kann, schädlich ist. Denn dadurch kann viel TPM-Hardware nicht als Passkey-Wallet bzw. -Datenbank funktionieren.
    Die meisten Kommentare dürften diesem Punkt zustimmen. Das rechtfertigt aber nicht die Verwirrung, die der Autor erzeugt, indem er die Hälfte des Artikels auf eine Definitionsdebatte über Passkeys verwendet.
  • Der Artikel setzt ziemlich viel Wissen über FIDO2 voraus, deshalb ist es völlig normal, dass er verwirrend ist.
    Passkeys werden auf FIDO2 implementiert und nutzen insbesondere die Resident-Key-Funktion der FIDO2-Spezifikation. FIDO2-Hardware-Authentifizierungsgeräte sind nicht exakt HSMs, aber ähnlich; es gibt auch Geräte wie Yubikey, die sowohl HSM als auch FIDO2-Authentifizierungsgerät sind. In FIDO2 sind „Resident Key“ und „discoverable Key“ Synonyme. Die Spezifikation verwendet „Resident Key“, aber „discoverable Key“ ist ebenfalls gebräuchlich; das ist einer der verwirrenden Begriffe, die FIDO hervorgebracht hat. Mit „Key“ ist nicht ein Passkey oder ein in einem HSM gespeicherter Schlüssel gemeint, sondern ein FIDO2-Hardware-Authentifizierungsgerät wie ein Yubikey, das häufig „Security Key“ genannt wird. Solange ein FIDO2-Hardware-Authentifizierungsgerät keine Resident Keys verwendet, ist es praktisch zustandslos und speichert nichts; deshalb kann es für unbegrenzt viele Konten registriert werden. Wenn es für ein Konto registriert wird, erzeugt das Gerät ein Schlüsselpaar, etwa EdDSA, speichert es aber nicht, sondern verschlüsselt den privaten Schlüssel mit einem eingebauten Master Key, zum Beispiel einem AES256-Schlüssel. Anschließend sendet es den Klartext-Public-Key und den verschlüsselten privaten Schlüssel an die Relying Party, etwa google.com, damit diese sie speichert. Bei der Authentifizierung wird der verschlüsselte private Schlüssel, also der „umhüllte“ Schlüssel, an das Authentifizierungsgerät übertragen, dort entschlüsselt und dann zur Erstellung einer digitalen Signatur verwendet. Allerdings schreibt FIDO2 nicht tatsächlich vor, wie Non-Resident Keys zu implementieren sind; umhüllte Schlüssel sind nur eine Methode. FIDO2 verlangt lediglich, dass der private Schlüssel sicher aus der Credential ID ableitbar sein muss, und die Credential ID ist beliebige Daten, die ein umhüllter Schlüssel sein können, aber nicht müssen.

• Das erscheint mir zu pessimistisch. Wenn man die Vorteile eines neuen Authentifizierungsstandards nutzen will, der schwache Passwörter und Passwort-Wiederverwendung eliminiert und damit 99 % der alltäglichen Kontoübernahmen verhindert, könnte man auch sagen, dass man von einem alten Yubikey, der seit 2013 durchhält, wegkommen und 30 Dollar für ein Upgrade ausgeben sollte.

  • Ich verstehe nicht, warum man zu einem Upgrade gezwungen werden sollte. Nicht-residente Keys eliminieren ebenfalls schwache Passwörter und Passwort-Wiederverwendung. Residente Keys fügen nur die kleine Verbesserung hinzu, dass der Dienst weiß, zu welchem Konto der Key gehört, wenn man ihn einsteckt; das scheint kein legitimer Grund zu sein, alle derzeit genutzten bestehenden Authentifizierungsgeräte auszumustern.
  • Laut dem technischen Handbuch der 5er-Serie werden nur 25 unterstützt. Im Moment habe ich zwar nur 2, aber bei TOTP sind es deutlich mehr als 25.
    Ich weiß nicht, wie es beim Bio-FIDO-Modell aussieht, aber wenn es ähnlich ist, hat YubiCo möglicherweise kein Produkt, das für eine große Zahl residenter Keys gut geeignet ist. Korrektur: Auch beim Bio gilt dieselbe Grenze von 25.
  • Ich sehe das eher als eine zu wohlwollende Interpretation.
    Geteilte residente Keys sollten, abgesehen von kurzfristiger temporärer Nutzung, gar nicht existieren. Sie sind eine Haftungsfrage, ein Sicherheitsrisiko und fördern schlechte Sicherheitspraktiken. Das beste Beispiel ist TOTP, das aus Sicherheitssicht viele Mängel hat. Man sollte ein Shared Secret nicht über mehrere Geräte verteilen oder sichern wollen; aber weil es möglich ist und schlampige 2FA-Implementierungen nicht die Ausnahme, sondern der Standard geworden sind, wird man praktisch dazu gezwungen. Wenn man sich die aktuelle Entwicklung ansieht, werden Passkeys wohl in dieselbe fehleranfällige und nutzerfeindliche Richtung gehen.
  • Trotzdem ändert sich dadurch nicht viel. Mein Key kann nur 25 residente Keys speichern, aber in meinem Passwortmanager liegen mehr als 25 Passwörter.
  • Ich befürchte, dass es künftig keine andere Wahl mehr geben wird, als diesen „Vorteil“ zu wählen. Wenn Websites den neuen Authentifizierungsstandard implementieren, werden sie dann die heutigen Benutzername/Passwort/2FA-Optionen weiterhin als Alternative beibehalten?

• Authentifizierung auf Basis von „etwas, das man besitzt, aber verlieren kann“ ist grundlegend kaputt. Wenn man das Gerät verliert, verliert man den Zugriff — oder die schwächste Stelle muss woanders liegen, wodurch die überragende Sicherheit bedeutungslos wird.

  • Man kann Backup-Codes ausdrucken oder einen zweiten Schubladen-Key hinzufügen. Die Idee an sich ist hervorragend, aber das Marketing ist sehr schlecht, der Einrichtungsablauf für normale Nutzer merkwürdig, und AirDrop-fähige oder cloud-synchronisierte Keys zu forcieren ist ebenfalls eine schlechte Idee. Das wichtigste Problem sind die Kosten der Keys.
  • Gilt das nicht auch für Passwörter? Menschen verlieren auch Passwörter häufig.
    Das wird sich an den Ergebnissen zeigen, aber wenn Passkeys breit eingeführt werden, dürfte Account-Lockout für die Mehrheit eher seltener als häufiger werden.

• Ich frage mich, warum der Speicherplatz von Hardware-Keys so stark begrenzt ist. Wie viel teurer wäre es, in den Key zusätzlich einen Massenspeicher einzubauen, auf den der sichere Prozessor zugreifen kann?
  Dieser Massenspeicher sollte natürlich vom sicheren Prozessor stark verschlüsselt werden, und wenn alles gelöscht wird, sollte auch dieser Schlüssel mit gelöscht werden.

  • Weil sicherer manipulationsgeschützter Speicher teuer ist.
    Aus Sicherheitssicht könnte man sogar sagen, dass ein Security Key mit 0 Speicher der beste Security Key ist. Protokolle, bei denen Security Tokens nicht aus Shared Secrets usw. abgeleitet, sondern in Security Keys oder Secure Enclaves injiziert und dort gespeichert werden, hatten meist gravierende Mängel. Manchmal sind es grundlegende Sicherheitsmängel wie bei TOTP, manchmal Komplexitätsmängel. Ebenso sollte man HSK-/2FA-Security-Keys niemals über mehrere Geräte teilen wollen. Wenn sie auf einem Gerät abfließen, ist alles kompromittiert. Stattdessen sollte jedes Gerät einen eigenen Key haben; für Login-Anbieter oder serverseitig ist dieser Overhead im großen Ganzen vernachlässigbar.
  • Das wirkt wie eine bewusste Designentscheidung, solche Geräte so „dumm“ wie möglich zu halten. Sobald man Speicher hinzufügt, öffnet man dieselbe Angriffsfläche wie bei anderen Speichergeräten; als Nächstes kommen Rechenfunktionen dazu, und am Ende ist es kein dummer Yubikey mehr, sondern ein vollständiger Computer.
  • Man könnte den Speicherplatz zwar vergrößern, aber je mehr man hineinpackt, desto höher wird auch die Ausfallwahrscheinlichkeit. Die heutigen Keys halten ziemlich grobe Behandlung aus, bevor sie nicht mehr funktionieren.
    Kleiner Speicher hat außerdem den Vorteil, dass er etwas leichter zu auditieren ist. Natürlich könnte selbst diese geringe Größe nach heutigen Maßstäben bereits den realistisch auditierbaren Rahmen ausreizen.
  • Es ist weniger so, dass der Speicher begrenzt ist, sondern eher so, dass das System von Anfang an so entworfen wurde, dass es keine Speichergrenze gibt.
    Beim TPM ist die Eingabe jedes Mal, wenn etwas signiert wird, die zu signierende Datenmenge plus der versiegelte private Schlüssel. Der versiegelte Schlüssel ist ein vom TPM erzeugter privater Schlüssel, der symmetrisch mit einem im TPM eingebauten Schlüssel verschlüsselt wurde. Diesen versiegelten Schlüssel speichert man auf einem Massenspeicher und übergibt ihn bei jedem Signiervorgang an das TPM. Durch dieses Design kann man so viele Schlüssel haben, wie der Massenspeicher erlaubt.
  • Man könnte es auch modular machen. Etwa ein Produkt verkaufen, das wie ein USB-Stick aussieht, hinten aber einen Slot hat, in den ein Security Key mit kleinem Formfaktor wie ein YubiKey Nano gesteckt wird.
    Wenn man den Security Key in den Slot steckt, stellt der USB-Stick dem Security Key Speicherplatz bereit und erscheint dem Computer wie ein Security Key. Wenn kein Security Key eingesteckt ist, funktioniert er als normaler USB-Stick. Normalerweise lässt man den Security Key eingesteckt; wenn man mehr Speicher braucht, kauft man ein größeres Speichermodul, nimmt den Security Key aus dem alten Modul, steckt es in den Computer, kopiert die verschlüsselten Dateien, überträgt sie auf das neue Modul und steckt den Security Key wieder ein.

• Ich bin mir grundsätzlich nicht sicher, ob es eine gute Idee ist, physische Sicherheitsschlüssel als Passkeys zu verwenden. Passkeys sind als Passwort-Ersatz gedacht, und dafür scheint man normalerweise die Zwei-Faktor-Eigenschaften zu brauchen, die ein Smartphone oder Desktop bietet: zusätzlich zu „etwas, das man besitzt“ auch „etwas, das man weiß“ oder „etwas, das man ist“ zum Entsperren.
  Physische Sicherheitsschlüssel sollte man meiner Meinung nach besser als zweiten Faktor belassen, der in bestimmten Hochsicherheitskontexten zusätzlich zu Passkeys verwendet wird. Besonders dann, wenn Klon-Resistenz die Kernfunktion ist. Für diesen Zweck braucht man keinen resident key, weil man bereits weiß, bei welchem Konto man sich anmelden will, wenn man beim zweiten Schritt ankommt. Außerdem halte ich die Autovervollständigungsfunktion, die resident keys bieten, für wichtig für die Passkey-UX. Es ergibt keinen Sinn, sie zu opfern, nur um Abwärtskompatibilität mit ein paar Schlüsseln aufrechtzuerhalten, die nur von Sicherheitsnerds genutzt werden. Wenn es natürlich eine Möglichkeit gibt, diese UX auch ohne resident keys zu erhalten, wäre das in Ordnung.

  • Im Großen und Ganzen sehe ich das genauso. Die Idee, auf die sich derzeit alle zubewegen, ist, einen vertrauenswürdigen, lokal verschlüsselten Tresor zu haben und sich gegenüber diesem System ausweisen zu müssen. Das kann ein Passwort sein oder ein Schlüssel.
    Es ist einfacher, dem gewählten Passwortmanager mehr Sicherheit zuzutrauen, als anzunehmen, dass jeder Dienst der Welt, bei dem man ein Konto anlegt, sicher oder nicht phishbar ist. Wenn man Passkeys verwendet, befindet man sich daher häufig bereits in einem sichereren Kontext, in dem man seine Identität gegenüber dem Betriebssystem oder einem Passwortmanager, der die Passkeys besitzt, etabliert hat. Außerdem ist es sehr wahrscheinlich, dass Stellen, die aktuell oder bis vor Kurzem keine Hardware-Keys unterstützt haben, diese auch in naher Zukunft nicht unterstützt hätten. Eine Passkey-Lösung dagegen ist viel einfacher einzuführen, weil die Kosten im Wesentlichen bei Software-Support liegen, und dürfte damit einen deutlich besseren Return on Investment haben. Das gilt natürlich vor allem für Websites; Passkeys sind eher so etwas wie „standardisierte SSH-Keys“ für Websites. Hardware-Keys erscheinen nützlicher als zweiter Faktor, der den Tresor mit den Passkeys tatsächlich öffnet; dabei kann zusätzlich auch ein Passwort erforderlich sein. Die Lebensdauer von Hardware-Keys dürfte noch nicht ganz vorbei sein. Nachdem ich sie bei GitHub, Gmail usw. als Standardmethode ausprobiert habe, ist der Passkey-Login-Flow wirklich sehr gut.
  • Passwortmanager haben Passwörter bereits überflüssig gemacht. Abgesehen von meinem Master-Passwort kenne ich keines meiner Passwörter. Passkeys sind eine übermäßig komplexe Lösung, die wir nicht wirklich brauchen.
    Der Browser bräuchte nur eine einfache HATEOAS-API, an die sich Passwortmanager anbinden können, und Web-Apps müssten HTML bereitstellen, das den Browser auslöst. Dann entscheidet der Passwortmanager, wie er den Nutzer authentifiziert, also auf die vom Nutzer gewünschte Weise, injiziert automatisch das Secret für die jeweilige Website, und der Nutzer wird automatisch angemeldet. Wenn etwas schiefgeht, nutzt man den E-Mail-Reset. Ich verstehe, dass Websites, die „besonders schicke Sicherheit“ wollen, etwas Komplexeres möchten. Aber Nutzer sollten optional ein höheres Sicherheitsniveau aktivieren können. Für die meisten Websites reicht zum Beispiel ein einfacher Passwort-Hash, wenn man davon ausgeht, dass der Passwortmanager zufällige Passwörter verwendet. Das kann jede Website implementieren, jeder Passwortmanager kann es implementieren, und es ist besser als die aktuelle Passwortnutzung von 99 % der normalen Nutzer. Das sollte die Standard-Authentifizierungsmethode sein. Wenn danach TOTP, OIDC, Public-Key-Kryptografie usw. gewünscht sind, kann der Server das anbieten und der Client optional daran teilnehmen, um die Authentifizierung fortzusetzen. Nicht jede Website und nicht jeder Nutzer muss die sicherste Methode verwenden. Man sollte es zunächst einfach machen, die Sicherheitsbasis anzuheben, und stärkere Sicherheit anschließend schrittweise optional machen.
  • Wenn man mit einem Yubikey passwortlose Authentifizierung (FIDO2) nutzt, wird vor der Aufforderung, das Gerät zu berühren, eine PIN verlangt. Wenn man die PIN zu oft falsch eingibt, wird der Yubikey gesperrt, ein Zurücksetzen des Geräts wird nötig, und alle bestehenden Registrierungen, bei denen dieser Key zur Authentifizierung verwendet wurde, werden ungültig.
    Es wirkt nicht wie ein großes Problem, wenn jemand mein Hardware-Token stiehlt. https://support.yubico.com/hc/en-us/articles/4402836718866-U...
  • Wenn man darüber nachdenkt, lässt sich das Kernproblem als „Authentifizierung eines biologischen Wesens gegenüber einem elektronischen System“ beschreiben.
    Bei Passwörtern ist die Authentifizierungsschnittstelle die Tastatur, und es gibt keine echte Garantie, dass die Person, die das Passwort eingibt, tatsächlich die Person ist, die sie zu sein behauptet. Passwörter beruhen auf leicht übertragbarem Wissen und können daher auf viele Arten abgegriffen werden. Es ist viel besser, die Authentifizierungsschnittstelle von Gerät zu Gerät zu verlagern. Statt anzunehmen, dass leicht übertragbares Wissen nicht weitergegeben wurde, nimmt man an, dass das biologische Wesen ein Authentifizierungsgerät verwalten kann — und darin sind Menschen ohnehin ziemlich gut. Man kann die Zahl der Authentifizierungskanäle erhöhen, um das Ganze robuster zu machen, und die Authentifizierung zwischen dem biologischen Wesen und dem Gerät, das für die Authentifizierung gegenüber entfernten Systemen genutzt wird, etwa wie FaceID einschränken. Im Kern fühlt es sich natürlich an, anzunehmen, dass ein Gerät wie ein Smartphone oder ein Schlüssel die Person repräsentiert. Zu Hause teilen wir nicht nur das Netflix-Passwort, sondern auch eine Kreditkarte. Aus praktischen Gründen liegt eine Kreditkarte zusammen mit einem Ersatzschlüssel bereit, und wenn jemand etwas fürs Haus kaufen muss, kann er sie einfach nehmen und verwenden. Wir vertrauen einander, dass die Karte korrekt genutzt wird, und alle kennen die PIN, aber weil kontaktloses Bezahlen üblich ist, braucht man sie fast nie. Das ist viel natürlicher, als Ausgaben zu verfolgen und später miteinander abzurechnen. Wahrscheinlich ist es illegal, und wenn die Bank davon wüsste, würde sie die Karte wohl sperren. IT-Systeme müssen dringend näher an menschliches Verhalten heranrücken, indem sie auf ähnliche Weise funktionieren wie die reale Welt. Weil ich mit IT-Systemen zu tun habe, halte ich das meiste aus, aber für technisch weniger versierte Menschen sind schon alltägliche Fragen schwierig: Was ist das iPhone-Passwort, was ist das iCloud-Passwort, was ist das Gmail-Passwort, warum muss ich in WhatsApp einen Code eingeben? Ehrlich gesagt habe selbst ich Mastodon nicht verstanden. Gegen Mastodon-Phishing wäre ich vermutlich schutzlos, und ich würde wahrscheinlich alles eingeben, was der Bildschirm von mir verlangt.
  • Die Aussage, Passkeys seien ein Passwort-Ersatz, stimmt nicht.

Passkeys schmarotzen, dem Namen zum Trotz, am FIDO2-U2F-Standard, der als zweiter Faktor entwickelt wurde. Resident Keys sind für eine geräteinterne Zwei-Faktor-Authentifizierung mit PIN gedacht und ein funktionaler Ersatz für Smartcards. Irgendjemand, vermutlich Apple, scheint gedacht zu haben, dass WebAuthn allein als einziger Authentifizierungsfaktor ausreicht. Keine Resident Keys, keine Hardware-Bindung, die Schlüssel wandern über iCloud, sind auf dem Gerät aber durch Touch ID/Face ID geschützt – so ungefähr. Und das wurde als Passkeys gebrandet. Zwei-Faktor-Authentifizierung an sich ist nicht das Ziel. Das Ziel ist eine Benutzerauthentifizierung, die gegen Phishing, Brute-Force- und Credential-Stuffing-Angriffe sicher ist und nicht so schwer zu implementieren ist wie Smartcards. FIDO2 leistet das. Das Problem der Implementierungen von Apple, Google und Microsoft ist nicht, dass die Sicherheit auf Protokollebene zwischen der authentifizierenden Website und dem Gerät des Nutzers gering wäre. Das Protokoll ist dasselbe. Das Problem ist, dass die Website nun dem persönlichen Plattformkonto des Nutzers vertrauen muss – darauf, dass der Nutzer es korrekt eingerichtet hat und dass sich die Plattform auch künftig immer korrekt verhält und Angriffe auf das persönliche Konto des Nutzers angemessen behandelt.

• Zur Einordnung: Ich betreibe ein von YC unterstütztes Unternehmen für passwortlose Authentifizierung und habe diese in großen Organisationen ausgerollt. Es scheint klar, dass Passkeys die Antwort für passwortlose Authentifizierung im Consumer-Bereich sein werden, aber in Unternehmensumgebungen spiegelt sich das offenbar noch nicht entsprechend wider.
  Passkeys sind großartig für Verbraucher. Denn sie zielen darauf ab, Anmeldedaten über Mechanismen wie das standardmäßige iCloud-Backup oder AirDrop auf andere Geräte zu sichern und so selbst einen Notfallzugang zu ermöglichen. Technisch können die Geräte, mit denen diese Anmeldedaten geteilt wurden, keine Attestation liefern. Attestation ist der „Nachweis“, dass ein Schlüsselpaar auf einem bestimmten Gerät wie einem Yubikey oder einem Apple-Gerät erzeugt wurde. Hersteller wie Yubico liefern Schlüssel mit eingebetteten, nicht extrahierbaren Schlüsselpaaren und Zertifikaten aus; da es keine externe Schnittstelle für den Zugriff auf dieses Schlüsselpaar gibt, kann ein Administrator mit hoher Sicherheit davon ausgehen, dass es sich um einen echten Yubikey handelt. Wenn es keine Attestation gibt und Schlüssel geteilt werden können, sieht man, wo die Probleme beginnen. Unternehmen wollen nicht das Risiko eingehen, dass per AirDrop übertragbare Anmeldedaten den Zugriff auf privilegierte Mitarbeiterkonten offenlegen. Bei einem Yubikey besteht praktisch kein Risiko digitalen Diebstahls. Letztlich können Passkeys auch nicht zum Entsperren von Geräten oder Servern verwendet werden. FIDO2 und, noch wichtiger, die Entwickler von Betriebssystemen haben noch einen langen Weg vor sich, wenn sie Passwörter vollständig abschaffen wollen. In weiten Teilen des heutigen Unternehmensmarkts füllt Yubikey diese Lücke, und manche haben Millionen Dollar in Hardware investiert. Passkeys in ihrem aktuellen Zustand dürften schwer zu verkaufen sein.

  • Passkey ist kein technischer Begriff, sondern ein Erfahrungsbegriff. Deshalb bricht er in technischen Argumentationen bis zu einem gewissen Grad zusammen.
    Apple unterstützt Passkeys, Android und Chrome ebenfalls, Microsoft auch, und Yubikey unterstützt Passkeys ebenfalls. Aber Funktionen und Einschränkungen wie das Authentifizierungsverfahren zur Nutzerverifikation und die Möglichkeit der Replikation können sich stark unterscheiden. Behörden können Passkeys unterstützen, sie aber nur zulassen, wenn sie von FIPS-zertifizierten Authentifizierungsgeräten bereitgestellt werden, die AAL2-Anforderungen erfüllen. Zumindest aktuell kommt so etwas nicht von Apple oder Google. Unternehmen können sich dafür entscheiden, Passkeys zu unterstützen, die von Software und Konfigurationen erzeugt werden, die ein MDM-verwaltetes Produkt bereitstellt, und Apple hat dafür Beta-Support angekündigt. Wenn man jedoch bei Government-to-Citizen-Diensten ein bestimmtes Hardware-Authentifizierungsgerät erzwingen will, dürfte das viel Schmerz verursachen. Es ist schwer, Bürger davon zu überzeugen, Hardware für über 80 Dollar zu kaufen, und da Web-Technologien um die Wahlfreiheit der Nutzer herum gebaut sind, ist es auch unwahrscheinlich, dass die WebAuthn-API und die User Experience in eine Richtung optimiert werden, die Einschränkungen der Nutzerwahl unterstützt.
  • Was passiert, wenn Google oder Apple aus unsinnigen Gründen wie Bot-Abwehr oder Betrugserkennung versehentlich ein Konto sperren?
  • Yubikeys 5 können als Passkeys verwendet werden.

• Aus Sicherheitsperspektive halte ich das für eine wirklich miserable Lösung.
  Für Regierungen und Unternehmen wie Apple und Google ist das eine traumhafte Struktur, um das digitale Leben zu kontrollieren. Wenn man Passwörter nutzt, ist das gewissermaßen nahezu zustandslos: Selbst wenn man mit einem privaten E-Mail-Konto oder irgendeinem Konto eine Grenze überquert, kann niemand wissen, dass man dieses Konto besitzt, und es ist schwierig, einen zur Herausgabe des Zugriffs zu zwingen, Zugriffselemente aus Hardware zu extrahieren oder einen auszusperren, weil man den Gerätezugriff verloren hat. Selbst wenn Master Keys und Ähnliches in einem TPM oder Secure Element gespeichert werden, haben manche Regierungen Zugriff darauf; es ist also nur eine Frage von Jahren und Rechenleistung. In den meisten Fällen ist das an sich auch ein Nachweis dafür, dass man Anmeldedaten für ein bestimmtes Konto besitzt. Geräte- oder Betriebssystemhersteller können von Behörden leicht gezwungen werden, Zugriff auf Sicherheitsbereiche bereitzustellen, und das kann freiwillig oder unfreiwillig geschehen.