FIDO Passkeys 3 – In Zukunft ohne Passwort
Im Teil 2 meiner Artikelserie habe ich die Funktionsweise der Passkeys erklärt und dargestellt, welche Abläufe während Registrierung und Authentifizierung durchgeführt werden.
In diesem Teil schauen wir uns Vorteile der FIDO Passkeys an und wo sich etwaige Stolpersteine befinden. Zudem blicken wir auf die Verbreitung und Implementierung der Passkeys und auf die Zukunft der Passwortmanager.
Die Vorteile von Passkeys
Domänengebunden und phishing-resistent
Jeder erzeugte Passkey ist nur für die Domain gültig, für die er generiert wurde. Eine Nutzung eines Credentials auf einer Website, die vorgibt, eine andere Website zu sein und unter einer absichtlich ähnlichen Domain erreichbar ist, ist nicht möglich, das muss der Authentifikator-Part verhindern. Hier können Nutzer:innen nicht eingreifen und sich versehentlich auf einer Phishing-Webseite anmelden. Passkeys sind resistent gegen Phishing-Versuche und potentielle Angreifer gehen leer aus.
Allerdings kann dies im weiteren Lebenszyklus einer Website, bzw. des Unternehmens, welches diese Website betreibt, auch einige neue Herausforderungen mit sich bringen: Falls sich das Unternehmen umbenennt oder der Webshop umbenannt wird und unter einer anderen Domäne erreichbar ist, gelten die bestehenden Passkeys der Benutzer:innen nicht mehr. Alle Nutzer:innen sind damit gezwungen, neue Passkeys zu hinterlegen.
Keine komplexen Passwort-Regeln
Da die Schlüsselpaare aufgrund von komplexen kryptographischen Algorithmen erzeugt werden und dies zudem automatisch passiert, ist ein Passkey automatisch zum einen sicherer (weil komplexer) als ein von Menschen ausgedachtes Passwort und zum anderen muss sich kein Mensch mehr mit mehr oder minder sinnvollen Passwort-Regeln rumärgern. Wie oft habe ich schon mehrfach ein generiertes Zufalls-Passwort manuell angepasst, nur weil die Webseite irgendwelche Sonderzeichen aus unerklärlichen Gründen nicht akzeptiert hat!?
Und was wir uns nicht ausdenken, müssen wir uns auch nicht merken, können wir also auch nicht vergessen. Die Verwaltung der Passkeys und deren Verwendung auf der richtigen Website übernehmen der Browser bzw. der Authentifikator für uns. Wenn ich allerdings keinen Zugriff auf den irgendwo gespeicherten Passkey habe, habe ich auch keine Chance, mich mit dem Passkey anzumelden. Ein Passwort könnte man ja vielleicht doch noch irgendwann in Erinnerung rufen. Aber das wollen wir ja eigentlich gar nicht mehr...
Automatisch Multi-Faktor
Um einen Passkey zu verwenden, benötige ich zum einen den privaten Schlüssel selbst, das ist der erste Faktor (Ownership – Besitz). Da der Passkey in einem sicheren Speicherbereich des Gerätes gespeichert wird, mit dem wir uns anmelden wollen (Authentifikator), müssen wir den Zugriff auf diesen Speicherbereich zunächst mit einem zweiten Faktor autorisieren. Dies geschieht am besten über die Nutzung eines biometrischen Merkmals, wie Fingerabdruck oder Gesichtserkennung (Inherence – innewohnende Eigenschaft).
Letztendlich ist diese Methode aber nicht wirklich Bestandteil der Authentifizierung, d. h. unser Fingerabdruck oder unsere Gesichtsform ist nicht Teil des Passkeys. Das biometrische Merkmal gibt nur den Zugriff auf den privaten Schlüssel des Passkeys frei, so dass dieser zur Authentifizierung verwendet werden kann. Ist der Fingerabdruck-Sensor kaputt oder keine Kamera vorhanden, um unser Gesicht zu erkennen, kann immer auch noch das Geräte- bzw. Betriebssystem-Passwort eingegeben werden, um den Zugriff zu autorisieren. Letztendlich ist das biometrische Merkmal nichts anderes als ein Ersatz für das OS-Kennwort. Damit ändert sich der zweite Faktor zum Wissen (Knowledge).
Keine Übermittlung persönlicher Daten
Bei der Verwendung von Passkeys wird nur der öffentliche Schlüssel an den Server übergeben und dort gespeichert. Wir müssen keine Informationen teilen, also kein shared secret (das Passwort) auf dem Server speichern lassen und hoffen, dass dies ausreichend sicher gegen Angriffe geschützt wird. Alleine mit dem öffentlichen Schlüssel unseres Passkeys können Angreifer nichts anfangen, dieser ist nutzlos für sie. Damit ist es sogar möglich, den öffentlichen Schlüssel im Klartext, also nicht gehasht, auf dem Server zu speichern. Der Schlüssel ist ja – öffentlich!
Es werden auch sonst keine persönlichen Daten in Zusammenhang auf dem Server der Webseite gespeichert. Wenn biometrische Methoden als 2. Faktor verwendet werden, werden diese Daten ja, wie oben erwähnt, nicht zur Authentifizierung genutzt, sondern nur zur Autorisierung, um den privaten Schlüssel verwenden zu dürfen. Somit werden diese Daten auch in keiner Weise an den Webserver übertragen.
Kleine Ausnahmen – Discoverable Credentials
Das oben Gesagte, dass keine persönlichen Daten mit dem Credential übermittelt und gespeichert werden, ist je nach Auslegung der DSGVO ggf. nicht ganz korrekt. Passkeys sehen die Verwendung von sog. Discoverable Credentials vor (auch bekannt unter der Bezeichnung Resident Keys). Mit Discoverable Credentials ist es möglich, dass sich Nutzer:innen "nur" mit dem Passkey authentifizieren, "ohne" die explizite Angabe eines Nutzernamens.
Bei dieser Methode wird im privaten wie öffentlichen Schlüsselpart eine Credential-ID gespeichert, mit der eine eindeutige Identifizierung des Credentials möglich ist. Meldet sich ein:e Nutzer:in nun mit dem Credential an, ohne Nutzernamen anzugeben, wird in der übermittelten Signatur des Anmelderätsels die Credential-ID mit übermittelt und der Webserver kann das verwendete Credential eindeutig auflösen und einem Nutzer zuordnen. Da über die Credential-ID somit auch ein:e Nutzer:in identifizierbar wird, könnte das ein schützenswertes Datum im Sinne der DSGVO sein. Um sicherzugehen, sollte man sich eine rechtliche Beratung einholen.
Cloud oder nicht Cloud!?
Ein zentraler, wenn auch nicht unbedingt notwendiger Bestandteil der Passkey-Spezifikation ist die Synchronisierung der privaten Schlüssel über die Cloud. Bevor jetzt alle laut aufschreien und protestieren: Das ist nichts Neues, das machen die von allen gepriesenen Passwort-Manager genauso! Also, erst mal den Ball flach halten...
Natürlich ist der ursprüngliche und eigentliche Gedanke, dass der private Schlüssel eben privat bleibt und nur durch den/die Besitzer:in verwaltet werden soll. Das bringt aber hinsichtlich der Benutzbarkeit in der Praxis einige Herausforderungen, wenn nicht sogar Nachteile für die überwiegende Mehrheit der Benutzer:innen mit. Nicht Jede:r hat ständig einen besonders gesicherten Hardware-Speicher (z. B. USB-Sticks wie Yubikeys etc.) dabei oder möchte/kann einen solchen verwenden. Natürlich, das ist eine tolle Sache, aber wenn es so einfach zu verwenden wäre, dann wären diese doch sicherlich schon deutlich verbreiteter, als sie aktuell sind.
Auch stimme ich dem Grundsatz zu, dass Sicherheit und eine komfortable Benutzbarkeit sich in einem sehr großen Gegensatz befinden. Größtmögliche Sicherheit hat meist keinen Komfort und eine komfortable Benutzbarkeit lässt viel Sicherheit vermissen. Wie so oft im Leben ist die benutzerfreundliche Sicherheit oder der sicher(st)e Komfort immer ein Kompromiss für beide Seiten!
Wir leben heute unser digitales Leben schon überwiegend in der Cloud und lassen die Cloud viele unserer Daten synchronisieren. Ein Kontakt, den ich gerade mit dem Smartphone gespeichert habe, steht mir unmittelbar danach auch auf meinem Notebook zur Verfügung, wenn beide Geräte sich über dasselbe Cloud-Konto synchronisieren. Das machen die drei großen Anbieter Apple, Google und Microsoft heute schon und wir profitieren davon.
Sicherheit hat immer auch etwas mit Vertrauen zu tun!
Je nach Art und Größe unseres Arbeitgebers existieren Unternehmens-Clouds, die eine ähnliche Funktionalität abbilden. Somit können auch die privaten Schlüssel unserer Passkeys über die Cloud synchronisiert werden. Speziell geschützt versteht sich. Entsprechend so verschlüsselt, dass nur der/die Besitzer:in an die Daten kommt und niemand anders, auch nicht der Cloud-Provider. Wir müssen hier dem Anbieter vertrauen. Sicherheit hat eben immer auch etwas mit Vertrauen zu tun!
Mit diesem Ansatz wird es möglich, die privaten Schlüssel geräteübergreifend zu nutzen – vorausgesetzt, alle verwendeten Geräte nutzen dasselbe Cloud-Konto. Eine cloud-übergreifende Synchronisation, also zwischen Clouds verschiedener Anbieter, ist (noch?) nicht vorgesehen.
Mit ohne Cloud und in gemischten Umgebungen
Was kann ich aber tun, wenn ich entweder keine Cloud nutzen will oder kann oder mich in einer gemischten Umgebung befinde? Ich habe z. B. ein MacBook und ein iPhone, nutze damit die Apple iCloud sehr extensiv, bin aber auch Freund des Google Chrome Browsers. Chrome hat keinen Zugriff auf die in der Apple iCloud gespeicherten Schlüssel! Glücklicherweise gibt es auch hierfür Lösungen, die auch für eine "Cloudless-Nutzung" verwendet werden können.
CTAP – Client to Authenticator Protocol
"Das Client to Authenticator Protocol (kurz: CTAP [1]) ist ein Standard für ein Kommunikationsprotokoll, das die Interaktion eines Sicherheitsgerätes (Authentifikator) mit einem (informationstechnischen) Endgerät (Client) beschreibt und mit dem der Nutzer seine Zugriffsberechtigung für angemeldete Dienste mit erhöhter Sicherheit nachweisen kann." Wikipedia [2]
Klingt erst mal sperrig, wird aber recht schnell einfach verständlich: Wenn der verwendete Client (meist ein Browser auf einem Gerät) keinen direkten Zugriff auf einen Passkey hat (wie im Beispiel oben: Chrome-Browser auf Apple MacBook), kann ein Authentifikator wie z. B. ein Smartphone verwendet werden, welches in der Lage ist, einen QR-Code zu scannen und Zugriff auf den benötigten Passkey hat. Der Client generiert eine entsprechende URL mit dem Schema FIDO:/... (s. o. CTAP-Spezifikation), zeigt diese URL in einem QR-Code verpackt an.
Der Authentifikator scannt den QR-Code und bekommt damit die Informationen, für welche Webseite (Domain) eine Anmeldung erforderlich ist. Der Authentifikator ermöglicht dann die Lösung des Login-Rätsels und dessen Signatur mit Hilfe des privaten Schlüssels. Dass das Smartphone auf den privaten Schlüssel zugreifen darf, autorisiert der Besitzer mit einem weiteren, bestenfalls biometrischen Merkmal. Die signierte Lösung wird dann an den Client übermittelt, der diese dann zur Authentifizierung an den Webserver zurücksenden kann. Voraussetzung, dass CTAP funktioniert, ist, dass zwischen Client und Authentifikator eine Kommunikationsverbindung hergestellt werden kann (z. B. selbes Netzwerk, Bluetooth-Verbindung etc.).
Somit ist nicht nur die Nutzung in gemischten Umgebungen möglich, sondern man kann sein Smartphone auch so konfigurieren, dass Passkeys nicht automatisch über die Cloud synchronisiert werden und die Schlüssel somit nur auf dem Device bleiben. Eine Authentifizierung wird dann nur mit dem Smartphone als Authentifikator möglich, ohne dass man eine Verbindung zu einer Cloud benötigt. Für einen evtl. Datenverlust muss man dann aber selbst vorsorgen und entsprechende Backups anfertigen und diese so sicher wie möglich speichern.
Hardware-Sicherheitsschlüssel
Eine weitere Möglichkeit ist die Verwendung von sog. "Hardware-Sicherheitsschlüsseln". Der bekannteste Vertreter ist sicherlich der YubiKey[3]. Diesen Hardware-Sicherheitsschlüssel steckt man in den USB-Anschluss am Rechner. Browser, die Passkeys bzw. WebAuthn [4] unterstützen, können auf diesen Sicherheitsschlüssel zugreifen und von dort den benötigten privaten Schlüssel des Passkeys auslesen. Bei der Registrierung wird auf dem USB-Device das Schlüsselpaar generiert und gleich dort (und nur dort) gespeichert.
Ein YubiKey verlangt, je nach verwendetem Modell, mindestens das Berühren des USB-Sticks, damit der Zugriff auf den Speicher freigegeben wird. Neuere Modelle sind z. B. auch mit PIN-Eingabe oder Fingerabdruck-Scannern ausgestattet, so dass hier die Sicherheit noch einmal weiter erhöht wird.
Die Nutzung von USB-Sicherheitsschlüsseln funktioniert per se ohne Cloud, stellt dann aber wieder die gleichen Anforderungen wie die o. g. Variante "nur auf dem Smartphone" gespeicherter Passkeys: Der/die Nutzer:in muss selbständig für ein aktuelles und funktionierendes Backup sorgen!
Passwortmanager
Wer keinen USB-Stick am Schlüsselbund mit sich tragen möchte oder diesen auch gerne mal irgendwo vergisst (Sicherheit!), kann auch seinen (hoffentlich) liebgewonnenen Passwortmanager weiter verwenden. Alle großen Anbieter von Passwortmanagern haben ihre Produkte dahingehend angepasst (oder sind aktuell noch dabei), dass diese nicht nur Passwörter, sondern zukünftig auch Passkeys bzw. die privaten Schlüssel der Passkeys verwalten können.
Viele Passwortmanager sichern und synchronisieren die Daten auch wieder über eine Cloud. Hier kommt dann der gleiche Vertrauensanspruch zum Tragen, wie schon weiter oben in diesem Artikel beschrieben. Aber es gibt ja auch Passwortmanager, die ich ohne Cloudverbindung lokal bei mir auf dem Rechner betreiben kann. Nur, deren Speicherdatei muss ich dann auch wieder "irgendwie" sichern und ggf. auf allen Geräten zugänglich machen, die ich verwenden will.
Wo und wann kann ich Passkeys verwenden und einsetzen?
Die Betriebssysteme und Browser der drei großen Treiber des Passkey-Standards (Apple, Google und Microsoft) unterstützen die Verwendung von Passkeys bereits. Auch der Zugriff auf die Clouds der Unternehmen (Apple iCloud, Google-Cloud, Microsoft Hello) sind über Passkeys absicherbar.
Mozillas Firefox unterstützt zwar den WebAuthn-Standard und Passkeys über Hardware-Sicherheitsschlüssel, kann aber selbst derzeit noch keine Passkeys generieren und verwalten [5]. Eine Unterstützung ist angeblich bis Ende 2023 geplant.
Wie die Lage bei Ubuntu Linux aussieht, ist derzeit nicht ganz klar. Einige Webseiten schreiben etwas davon, dass es möglich wäre, andere, dass nur bestimmte Browser unter Linux Passkeys anbieten und wiederum andere, dass es, wie bei Firefox, nur mit Hardware-Sicherheitsschlüsseln funktioniert. Eine Device Support Matrix zeigt, dass Ubuntu noch ziemlich wenig Unterstützung aufweist [6].
Für Entwickler gibt es ebenfalls eine Seite mit Bibliotheken, welche für unterschiedliche Programmiersprachen bereits Implementierungen zur Verfügung stellen [7] und eine Seite, die Links zu Testseiten und Werkzeugen anbietet, auf denen jeder seine Umgebung, Betriebssysteme und Browser testen kann [8]. Die offiziellen Spezifikationen sind bei der FIDO Alliance zu finden [9].
Bei öffentlichen Websites sind technologieaffine Unternehmen und Plattformen, wie z. B. PayPal und GitHub, vorn mit dabei, wenn es um eine Passkey-Unterstützung geht. Andere Websites ziehen früher oder später nach bzw. müssen dies tun. Überraschenderweise findet man hier und da auch kleinere Unternehmen, die bereits eine Authentifizierung über Passkeys anbieten.
Wer Keycloak [10] zur Authentifizierung und das Identity-Management einsetzt, muss nur ein paar kleine Konfigurationseinstellungen vornehmen und kann dann, ohne weiteren Implementierungsaufwand, Passkeys in seiner Umgebung einsetzen und den Nutzer:innen anbieten.
Was Passkeys nicht lösen (können)...
Ein privater Schlüssel ist ein privater Schlüssel. Ist dieser einmal verloren gegangen, gibt es keine Möglichkeit mehr, ihn wiederherzustellen. Selbst in den Clouds soll dieser nur für Besitzer:innen selbst lesbar gespeichert sein.
Es muss also nach wie vor einen Prozess geben, der es Nutzer:innen ermöglicht, ihr Konto auch ohne den registrierten Passkey zu verwenden. Wenn auch ausschließlich dafür, um einen neuen Passkey zu hinterlegen.
Welche Methode hier zum Einsatz kommt, muss jeder Anbieter für sich selbst erörtern. Die einfachste, wenn auch eine der schwächsten Methoden, ist die des Passwortes als Ersatz für den Passkey. (Bessere) Alternativen gibt es aber sicherlich, z. B. die Nutzung von MagicLinks oder mehreren Faktoren etc. Letztendlich muss ein analoger Prozess zu dem eines vergessenen Passwortes etabliert werden.
Fazit
Die Frage ist nicht mehr, ob Passkeys kommen werden, sondern nur noch, wann sie endlich flächendeckend eingesetzt werden und verfügbar sind. Sind sie doch deutlich sicherer als herkömmliche Passwörter und dabei noch einfacher in der Verwendung.
Hinsichtlich Sicherheit punkten Phishing-Resistenz, da domänengebunden, die implizite Mehrfaktor-Voraussetzung und das automatische Handling durch Client und Authentifikator – Erinnerungslücken werden somit, zumindest in dieser Hinsicht, weniger relevant. Über die Synchronisation der privaten Schlüssel über eine Cloud mag man denken, wie man will, es ist jedoch der entscheidende Faktor, dass Passkeys für alle Anwender:innen nutzbar werden – auch geräteübergreifend. Mitentscheidend für den (baldigen) Erfolg von Passkeys ist nicht nur die Implementierung in Betriebssysteme, Browser und Anwendungen, sondern auch die klare und einfache Kommunikation des neuen Authentifizierungsverfahrens für alle Nutzer:innen.
Bis Passkeys letztendlich wirklich die gewohnten Passwörter ablösen werden, wird noch eine ganze Menge Zeit ins Land gehen. Wir alle können dazu beitragen, dass diese Zeit schneller vergeht, indem wir Passkeys bereits jetzt dort anbieten bzw. anwenden, wo wir einen Einfluss darauf haben und nicht erst "abwarten", was "Andere" machen. Gehen wir voran, setzen ein Zeichen und geben die Richtung für eine sicherere Zukunft vor!
- Client to Authenticator Protocol (CTAP)
- Wikipedia: Client To Authenticator Protocol
- Wikipedia: YubiKey
- Wikipedia: WebAuthn
- Bugzilla: Make the WebAuthn Soft Token a Real Thing
- passkeys.dev: Matrix
- passkeys.dev: Bibliotheken
- passkeys.dev: Test Sites & Tools
- FIDO Alliance
- Keycloak
