Passwörter könnten bald Geschichte sein – dank Passkeys. Wir wollen nicht nur einen schnellen Überblick über deren Funktionsweise geben, sondern auch in die Tiefe blicken. Wir zeigen, was du als Entwickler wissen solltest, wenn du deine Anwendung oder Website für eine passwortlose Zukunft rüsten willst.

In einer digitalen Welt, in der Sicherheitsbedrohungen immer herausfordernder werden, steht auch der Mensch im Fokus von Bedrohungsbetrachtungen. Unsichere Praktiken wie das manuelle Eingeben von Passwörtern eröffnen Angreifern potenzielle Angriffspunkte, um unbefugt in fremde Systeme einzudringen. Im Gegensatz dazu bieten Passkeys eine moderne und sichere Alternative, die das Risiko solcher Angriffe minimiert.

Obwohl Passkeys relativ neu erscheinen, da sie erst in den letzten ein bis zwei Jahren eine größere Verbreitung finden, basieren sie im Wesentlichen auf dem bereits 2018 eingeführten FIDO2-Standard. Er besteht hauptsächlich aus zwei Komponenten: WebAuthn (siehe Kasten „WebAuthn“) und CTAP (siehe Kasten „CTAP“). Aufbauend auf diesen Standards versprechen Passkeys, langfristig traditionelle Passwörter durch eine sicherere und benutzerfreundlichere Methode zu ersetzen, um die Identität eines Benutzers zu verifizieren. Doch wie funktionieren Passkeys genau, und warum sollten Unternehmen und Nutzer diese Technologie in Betracht ziehen?

Im Wesentlichen kann der Ablauf der Benutzerauthentifizierung mit Hilfe von Passkeys in zwei Schritten beschrieben werden: der Registrierung und dem Log-in. Beide sind auf Einfachheit und Sicherheit ausgelegt, um den Übergang zu einer passwortlosen Authentifizierung so reibungslos wie möglich zu gestalten.

So läuft die Registrierung ab …

Die folgende Beschreibung der Registrierung ist auch in Abbildung 1 veranschaulicht. Zunächst startet der Benutzer den Registrierungsprozess, indem er beispielsweise auf den Registrieren-Button klickt. Der Client stellt dann eine Anfrage an den Server für eine sogenannte Challenge, eine zufällig generierte Zeichenkette, und erhält diese als Antwort vom Server zurück.

Im nächsten Schritt ruft der Client das WebAuthn API auf, um Credentials für die Registrierung zu generieren. Daraufhin wird auf dem Authentikator ein Schlüsselpaar mit einem privaten und einem öffentlichen Schlüssel erstellt. Der private Schlüssel wird zum Signieren der Challenge verwendet und entweder lokal sicher auf dem Gerät des Benutzers gespeichert (z. B. TPM, Secure Enclave) oder bei einem Cloud-Anbieter abgelegt. Der zugehörige öffentliche Schlüssel, eine Credential-ID und die signierte Challenge werden vom API zurückgegeben. In diesem Schritt kann der Benutzer aufgefordert werden, sich durch biometrische Daten oder eine PIN zu verifizieren.

Zum Abschluss der Registrierung sendet der Client das Tripel, bestehend aus öffentlichem Schlüssel, Credential-ID und signierter Challenge, an den Server zurück. Der neu registrierte Benutzer wird von nun an mit der Credential ID und dem öffentlichen Schlüssel für Log-ins verknüpft.

… und so das Log-in

Der Log-in-Flow funktioniert analog zum Registrierungs-Flow (Abb. 2): Wenn sich der Benutzer anmelden möchte, startet er den Prozess, indem er auf einen Log-in-Button klickt. Daraufhin sendet der Client eine Anfrage für eine zufällige Challenge an den Server. Der Server generiert eine neue Challenge, die an den Client zurückgeschickt wird.

Der Client ruft nun das WebAuthn API auf, um die passenden Credentials vom Authentikator zu erhalten. Auf dem Authentikator wird der Benutzer dann aufgefordert, sich zu verifizieren. Das kann z. B. über eine biometrische Eingabe mit Fingerabdruckscan geschehen. Mit dem Passkey bzw. dem privaten Schlüssel signiert der Authentikator die Challenge und schickt diese zusammen mit dem Benutzernamen und der Credential ID an den Client zurück.

Um den Log-in-Vorgang abzuschließen, sendet der Client die Informationen, die er vom Authentikator bekommen hat (Benutzername, Credential ID, signierte Challenge) an den Server zurück. Sind dem Server Benutzername und Credential ID bekannt und wurde die Gültigkeit der Challenge mit dem öffentlichen Schlüssel erfolgreich überprüft, wird dem Benutzer der Zugang gewährt.

Passkeys lokal oder in der Cloud speichern

Wichtig für den Umgang mit Passkeys ist die Entscheidung, welche Art der Schlüsselverwaltung gewählt wird. Damit wird auch festgelegt, wo die Passkeys abgelegt werden. Grundsätzlich gibt es zwei Möglichkeiten: Zum einen speichert man sie lokal in einem sicheren Bereich, physikalisch isoliert, mit einem Hardwaremodul (z. B. TPM, Trusted Platform Module, oder USB-Sicherheitstoken). Andererseits ist es auch möglich, sie softwarebasiert in der Cloud abzulegen. Dies bietet den Vorteil einer höheren Flexibilität, da man seine Passkeys auf allen Geräten synchronisieren kann. Es eröffnet aber auch ein neues Einfallstor für Angreifer und kann somit die Sicherheit reduzieren. Im Folgenden werden die Vor- und Nachteile kurz zusammengefasst.

Hardwarebasierte Lösungen bieten eine höhere Sicherheit. Der private Schlüssel verlässt nie das Gerät, was das Phishing-Risiko deutlich verringert. Zudem sind solche Lösungen so konzipiert, dass ein direktes Auslesen oder Kopieren der privaten Schlüssel auf dem Gerät nicht möglich ist. Auch Datenschutzbedenken, die mit der Speicherung sensibler Daten in der Cloud verbunden sind, müssen die Nutzer weniger fürchten, und der Anwender wird unabhängig von Drittanbietern. Allerdings geht dieser Ansatz auch mit einer eingeschränkten Portabilität einher: Wenn ein Nutzer ein neues Gerät verwendet, muss ein neuer Schlüssel generiert und registriert werden, was die Nutzung etwas komplexer machen kann. Entscheidet sich der Benutzer zudem, ausschließlich Passkeys zu verwenden und keine Back-up-Optionen zu nutzen, so geht er das Risiko ein, bei Verlust des Authentikators den Zugang zu verlieren und damit aus der Anwendung ausgesperrt zu werden. Hier empfiehlt es sich, einen zweiten Authentikator als Fallback einzurichten.

Die zweite Möglichkeit zur Speicherung des privaten Schlüssels ist die Nutzung der integrierten Schlüsselverwaltung der Betriebssysteme von Apple (iCloud-Schlüsselbund), Google (Passwortmanager) und Microsoft (Windows Hello), die in der Cloud gespeichert und verwaltet werden. Der Vorteil dieser Lösung ist, dass die Schlüssel über mehrere Geräte hinweg synchronisiert werden können. Das erleichtert den Zugriff auf gesicherte Konten von mehreren Geräten aus und bietet eine nahtlose Benutzererfahrung. Verliert der Nutzer sein Gerät oder wird es beschädigt, kann er sich einfach von einem neuen Gerät aus anmelden, da der private Schlüssel in der Cloud verfügbar ist.

Dadurch wird die Wiederherstellung des Zugangs zu Konten erheblich vereinfacht, es eröffnet aber auch eine weitere Angriffsfläche. Die Speicherung sensibler Daten in der Cloud wirft potenzielle Sicherheitsfragen auf, insbesondere im Hinblick auf den Zugriff durch Dritte oder staatliche Stellen. Obwohl die Schlüssel in der Regel verschlüsselt sind, bleibt die Cloud ein attraktives Ziel für Angreifer.

Wer sich einmal für einen Anbieter entschieden hat, ist an dieses Ökosystem gebunden. Eine Migration, beispielsweise von Windows Hello zu iCloud-Schlüsselbund, ist von den Herstellern nicht vorgesehen. Der Nutzer muss dann die Schlüssel aufwendig neu generieren und speichern lassen.

Komfortabel anmelden: Cross-Device-Authentifizierung

Die Cross-Device-Authentifizierung ist ein wichtiger Baustein für die Praxistauglichkeit von Passkeys. Eine komfortable Anmeldung auf fremden Geräten ist nur damit möglich. In der CTAP2-Spezifikation [2] wird dies als „Hybrid Transport“ bezeichnet (ehemals cloud-assisted Bluetooth Low Energy, kurz caBLE). Wie das im Detail funktioniert, ist für die meisten Anwendungen nicht relevant. Die Umsetzung obliegt hier den Client-(Browser-) bzw. Plattform-(Betriebssystem-) und Authentikator-Anbietern.

Für die Nutzung müssen einige Voraussetzungen erfüllt sein. Beide Geräte...