FIDO Passkeys - In Zukunft ohne Passwort

Der Mensch ist ein Gewohnheitstier und tut sich mit Veränderungen bekanntlich sehr schwer! Nach der jahrelangen Existenz einer Passwort-basierten Authentifizierung, die wir alle kennen, steht nun eine Neuerung bevor: Die passwortlose Authentifzierung mittels sog. Passkeys. Das ist neu - und vor allem Neuen hat der Mensch erst mal Vorbehalte und vielleicht auch Angst. Ich möchte in dieser kleinen Artikelserie durch Auf- und Erklärung die Angst vor dem Neuen, Unbekannten, nehmen und mehr Licht ins Dunkel bringen. Was ist, was wird kommen, was wird uns erwarten und warum das alles? Lasst uns starten!

Die Sache mit den Passwörtern

Wir müssen reden! Noch immer verwenden wir, ja, auch auch wir Software-Entwickler:innen, viel zu oft das vermeintlich “Einfache”, weil bekannte “Sicherheitsverfahren” Passwort. Schon immer da, überall irgendwie implementiert, von Nutzer:innen mehr oder weniger akzeptiert, es gibt, neben Post-It’s am Monitor, Passwortmanager und wer’s noch sicherer haben möchte, kann ja auch noch eine Authenticator-App für die Generierung von OTPs einsetzen. Aber ist das wirklich alles so sinnvoll? Was nutzen wir hier eigentlich? Und woher kommt das alles?

Wie ist die Parole?

Um die vorgenannten Fragen beantworten zu können, müssen wir in der Geschichte etwas zurückgehen. Ein paar Jahre. Ein paar viele Jahre! Geschichtlich findet das Passwort in Form der “Parole” erstmals im 17. Jahrhundert im Kontext des Militärs Erwähnung: Die Parole ist ein militärisches Kennwort, das nur dem Kommandeur einer Abteilung bekannt gegeben wird, nicht aber den einfachen Soldaten. Bei Annäherung eines Truppenteils verlangt der Wachposten die Parole vom Kommandeur. Die Parole war also schon vor mehr als 500 Jahren ein “Shared Secret”, welches der Kommandeur (Benutzer:in) und der Wachposten (Server) kannte. Genauso machen wir es heute immer noch, dass Benutzer:innen ihr persönliches Datum einem fremden Server mitteilen und hoffen, dass dieser das Datum vertrauensvoll und sicher speichert. Sowohl der Kommandeur als auch der Wachposten waren schon damals angreifbar, sei es mit mechanischen Mitteln (Folter, Waffen, sprich: “Tools”) oder über “Social-Engineering”. Von Phishing-Versuchen gar nicht zu reden (“ich zieh mir mal eine Rüstung vom Gegner an” - auch der “Hauptmann von Köpenick” lässt grüßen!) Gleiches gilt heute noch für Benutzer:innen und Anbieter/Server.

Einzelne Anwender:innen zu manipulieren ist für Angreifende natürlich aufwändiger und schwerer, als eine Liste mit Passwörtern von einem Server abzugreifen. Leider ist dies immer noch möglich und leider sind immer noch zu viele Passwörter auf zu vielen Servern schlecht oder gar nicht gehasht gespeichert, also im Klartext einsehbar. Diese Listen landen dann auf Marktplätzen im Darknet und sind für mehr oder weniger Jedermann/-frau zu kaufen. Verschlimmert wird das dann noch dadurch, dass die Mehrheit der Nutzer:innen nur ein einziges Passwort für viele unterschiedliche Websites verwenden. Hat ein:e Angreifer:in also das Passwort von einer Seite, hat er/sie möglicherweise auch das Passwort zu vielen weiteren Seiten.

Das Konzept des Passwortes für Software-Anwendungen stammt zwar nicht aus dem 17. Jahrhundert, aber ungefähr aus den 1970er Jahren, einer Zeit, zu der ein:e Benutzer:in eben nur einen einzigen Zugang zu einem einzigen System, meist dem im Unternehmen des Arbeitgebers, hatten und sich auch nur dieses eine Passwort merken mussten. Lt. einer Umfrage hatten User 2017 bereits durchschnittlich 78 Online-Accounts. Heute dürfte die Zahl deutlich höher liegen. Eine nicht-repräsentative Umfage in meinem direkten Umkreis bringt es im Schnitt eher auf ca. 250-300 Konten, verteilt im Internet, mal mehr, mal weniger genutzt.

123456 ? - Ja, leider immer noch!

Nimmt man jetzt die im Darknet erhältlichen Listen von existierenden Online-Accounts, die Anzahl an Konten je Nutzer:in und die wahrscheinlich eher geringe Varianz an Passwörtern, wird es Angreifenden wirklich leicht gemacht, diese unsere Daten für ihre Zwecke zu missbrauchen. Von den Nutzer:innen selbst, wie aber auch von Website-Betreibenden, die diese Daten zu schlecht schützen. Auf der Seite SafetyDetectives.com gibt es eine schöne Auswertung dieser Passwort-Listen. Demnach ist 123456 immer noch das meistgenutzte Passwort - nicht nur in Deutschland, sondern weltweit! Die Nutzer:innen in den USA nutzen das auch gern verwendete password noch lieber als die Zahlenreihe. Generell sind Zahlen- oder Buchstabenreihen sehr beliebte “Passwörter”. Auch Muster, die über das Tippen auf der Tastatur entstehen, z.B. 1q2w3e4r, wenden User gerne an.

Schauen wir uns speziell in Deutschland um, fallen erwartungsgemäß Varianten wie passwort und hallo ins Auge. Auch Begriffe wie schalke04 sind erklärbar, enthalten sie doch Buchstaben und Zahlen. Solche Kombinationen sollen die Komplexität erhöhen und damit das Erraten von Passwörtern erschweren, was heute aber nur noch bedingt zutrifft. Woher allerdings dennis auf Platz 20 kommt, erschließt sich mir nicht. Ist es auf “Dennis aus Hürth” zurückzuführen? Oder ist der Film aus dem Jahre 1993 doch bekannter als ich dachte? Wir schweifen ab…

Dennoch haben wir bereits gute Anhaltspunkte, wie wir die Passwörter unserer Kolleg:innen möglicherweise rausfinden können. Leider zeigt die Analyse, dass diese Passwörter nicht mehr nur noch Einzelfälle sind, sondern immer noch gelebter Alltag. Website-Betreiber machen es sich hier recht einfach und schreiben lediglich min. 8-stellige Passwörter vor und schränken die Auswahl eines guten Passwortes auch noch damit ein, dass bestimmte Zeichen vorgeschrieben - oder, leider zu oft auch gesehen, sogar ausgeschlossen werden. Dabei sind die beiden einzig sinnvollen und zu mehr Sicherheit führenden Vorgaben für sinnvolle Passwörter: (1) mindestens viele Zeichen (ich empfehle Stand heute ab 16 Zeichen) UND (2) alle möglichen Zeichen erlauben! Nur dann wird das Erraten von Passwörtern mittels Brute-Force-Angriffen wirkungsvoll erschwert. Alles andere bewahrt nur davor, dass Kolleg:innen Siehe auch der bekannte xkcd-Comic über Passwortstärke. Passwortmanager helfen bei der Erstellung und Verwaltung von unterschiedlichen und sicheren Passwörtern. Leider werden diese immer noch von zu wenigen Anwender:innen verwendet. Und das, wo doch jeder Browser heute sogar einen eigenen Manager mitbringt, der auch (mehr oder weniger) sicher über die Cloud synchronisiert werden und damit auf allen Endgeräten komfortabel zur Verfügung stehen kann.

Aber MFA…!?

Für Ottonormalanwender:in (wer ist das überhaupt?) wird es also gefühlt immer schwerer, mit Passwörtern umzugehen, hat doch jede Website andere Anforderungen. Um es noch “sicherer” zu machen, kam irgendwer auf die Idee, dass doch so etwas wie eine Mehrfaktor-Authentifizierung (MFA) und Einmalpasswörter (One-Time-Password: OTP) eine gute Sache seien. Ohne näher darauf einzugehen, wie genau OTPs funktionieren, ist die grundsätzliche Verwendung von Mehrfaktor-Authentifizierung (Wissen, Besitz, Inhärenz) zwar eine gute Sache, erschwert den Missbrauch einer passwortbasierten Authentifizierung, erschwert aber auch gleichzeitig die einfache Verwendung für o.g. Ottonormalverbaucher:in. Nicht Jede:r ist geübt in der Benutzung von Browser, Passwortmanager und Apps zur Generierung eines OTPs… Zusätzlich ist der Einsatz von MFA und OTP auf den wenigsten Websites Pflicht, teilweise noch nicht mal optional möglich. Damit schieben die Betreiber:innen die Verantwortung auf die Nutzer:innen, die es dann ja einrichten können (falls überhaupt möglich), wenn sie es denn nutzen wollen.

FIDO Passkeys

Die FIDO Alliance hat sich auf die Fahne geschrieben, das Internet und die Nutzung dessen, gleichzeitig einfacher nutzbar und dennoch sicherer, durch eine stärkere Authentifizierung als derzeit üblich, zu machen. Auf der Website spricht die FIDO Alliance davon, das weltweite Passwort-Problem lösen zu wollen (“Solving the World’s Password Problem”). Die Abkürzung FIDO steht hierbei für Fast IDentity Online, also für eine schnelle Online Identifizierung von Nutzern im Internet. Die Mitglieder der FIDO Alliance sind viele große und bekannte Tech-Konzerne. Allen voran, treiben die Unternehmen Apple, Google und Microsoft (Nennung in alphabetischer Reihenfolge, keine Wertung) die Bemühungen rund um die FIDO Passkeys voran.

Der Begriff Passkey ist ein Kunstwort und lehnt sich, mit dem ersten Wortteil, an das bekannte Passwort an. Bei Passkeys werden aber keine Wörter als Shared Secret geteilt, sondern Passkeys basieren auf kryptographischen Schlüsseln, deshalb der zweite Wortteil Key. Der kryptographische Schlüssel besteht eigentlich aus einem Schlüssel-_Paar_ - ein privater Schlüssel und ein öffentlicher Schlüssel. Im Prinzip ist das Verfahren nicht neu, wird die Anmeldung mit einem sog. “Public/Private Keypair” doch schon jahrelang in anderen Umgebungen verwendet, wie z.B. dem SSH Login unter Unix/Linux Betriebssystemen. Aber auch in anderen Bereichen kommen diese Schlüsselpaare bereits seit langer Zeit zum Einsatz.

Die Grundidee hierbei ist, dass der private Schlüssel immer privat bleibt und nie herausgegeben wird, er verbleibt also immer bei der Identität, also dem/der Nutzer:in, der/die authentifiziert werden soll. Lediglich der öffentliche Schlüssel wird verteilt und kann von den authentifzierenden Stellen gespeichert und verwendet werden. Mit dem öffentlichen Schlüssel können nur Überprüfungen von mit dem privaten Schlüsseln erfolgten Signaturen vorgenommen werden. Es ist nicht möglich, mit dem öffentlichen Schlüssel eine Signatur für eine manipulierte Authentifizierung zu fälschen.

FIDO Passkeys basieren auf dem bereits 2019 verabschiedeten WebAuthn Standard, um mit Public-Private-Keypairs eine Authentifizierung im Webbrowser durchführen zu können. Ein Passkey ist immer für eine bestimmte Domäne gültig, kann nicht für mehrere Domänen verwendet werden. Durch diese Domänenbindung sind Passkeys automatisch Phishing-resistent, es kann also auf einer fremden Domäne keine versehentliche bzw. ungewollte Anmeldung geben. Angreifer kommen so weniger bis gar nicht an fremde Identitäten. Die Auswahl, welcher der gespeicherten Passkeys für eine Domäne verwendet wird, obliegt dem Browser, nicht dem Nutzer, was gleichzeitig die Sicherheit, als auch die Einfachheit der Anwendung erhöht. Damit die Nutzer eine weitere Unterstützung bei der Verwendung von Passkeys bekommen, können die privaten Schlüssel geräteübergreifend, unter Berücksichtigung weiterer Sicherheitsvorkerhrungen, synchronisiert werden, so dass z.B. ein auf einem Mobilgerät erzeugter Passkey auch vom Desktop-Rechner aus verwendbar ist.

Login / Authentifizierung

Schauen wir uns den Vorgang der Authentifizierung mit FIDO Passkeys einmal im Detail an. Die nebenstehende Animation verdeutlicht die Ablauf zusätzlich:

1. Ein Nutzer möchte sich wie gewöhnlich an einer Website (oder Mobile-App) anmelden.
2. Wenn die Website die Nutzung von Passkeys ermöglicht, kann der Browser dem Nutzer anbieten, diese zu nutzen
3. Zur Anmeldung mit einem Passkey, schickt die Website dem Browser eine sog. Challenge Response, also ein Rätsel, welches der Browser lösen und mit dem passenden privaten Schlüssel signieren und wieder an die Website zurücksenden muss.
4. Im Folgenden wird dem Nutzer ein auf dem Gerät gespeicherter (privater) Passkey zur Nutzung angeboten. Bei mehreren vorhandenen Passkeys bekommt der Nutzer die Möglichkeit, eine Passkey zu wählen.
5. Die Verwendung des gewählten Passkeys wird mittels einem weiteren Merkmal, bestenfalls ein biometrisches Merkmal wie Fingerabdruck oder Gesichtserkennung, bestätigt.
6. Mit der Bestätigung wird der Zugriff auf den sicheren Speicherbereich, wo der private Schlüssel abgelegt ist, freigeschaltet, der Browser kann das Rätsel lösen und mit dem privaten Schlüssel signieren. Im Anschluss sendet er die signierte Lösung an den Server der Website zur Überprüfung zurück.
7. Die Website prüft dann, ob das Rätsel erfolgreich gelöst wurde, und, ob die Signatur erfolgreich mit dem für den Nutzer auf dem Website-Server gespeicherten öffentlichen Schlüssel verifiziert werden kann. Nur der passende öffentliche Schlüssel zum privaten Pendant kann hierfür verwendet werden. Schlägt die Überprüfung der Signatur fehl, kann der Nutzer nicht erfolgreich authentifziert werden.
8. Passt die Signatur zum öffentlichen Schlüssel, ist alles erledigt, der Nutzer ist angemeldet. 😊

Der private Schlüssel verlässt bei dem o.g. Verfahren nie das Device des Nutzers, es wird lediglich die Lösung des Rätsels mit dem privaten Schlüssel signiert und diese Signatur kann von der Website mit dem öffentlichen Schlüssel verifiziert werden!

Registrierung

Damit sich ein Nutzer mit seinen Passkeys bei einer Website authentisieren kann, muss zunächst der öffentliche Schlüssel für den Nutzer auf dem Server der Website registriert, also gespeichert werden. Bestenfalls geschieht dies bereits bei der initialen Registrierung eines Nutzers, kann aber auch nachträglich durchgeführt werden. Bestehende Nutzerkonten müssen also nicht neu registriert werden (sofern der Website-Betreiber alles richtig macht).

Die nebenstehende Animation zeigt wieder den schematischen Ablauf:

1. Der Browser sendet eine Registrierungs-Anfrage an die Website.
2. Diese antwortet mit den Bedingungen an eine Schlüssel-Generierung. Eine Bedingung kann z.B. die Verwendung eines bestimmten kryptographischen Algorithmus’ sein.
3. Kann der Browser die geforderten Bedingungen erfüllen, wird der Nutzer gefragt, ob für den angegebenen Nutzernamen ein Schlüsselpaar für diese Website erzeugt (generiert) und gespeichert werden soll.
4. Diese Frage bestätigt der Nutzer, wieder unter Verwendung eines zusätzlichen Faktors (s.o., z.B. Gesichtserkennung, Fingerabdruck, etc.).
5. Mit dem zusätzlichen Faktor wird dann wieder der Zugriff auf den sicheren Speicherbereich für den Browser freigegeben, in dem dann das neue Schlüsselpaar für die Website generiert und gespeichert wird.
6. Im Anschluss sendet der Browser mit der Antwort den öffentlichen Schlüssel des Passkeys an den Server der Website, der diesen dann speichern kann. Der private Schlüssel verbleibt auf dem Gerät des Nutzers, dieser wird nicht verteilt!

Da mit dem öffentlichen Schlüssel alleine kein Missbrauch betrieben werden kann, ist es zudem nicht erforderlich, diesen auf der Serverseite zu hashen, wie es bei Shared-Secrets wie Passwörtern der Fall ist.

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 kann der/die Nutzer:in nicht eingreifen und sich versehentlich auf einer Phishing-Webiste 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 auch nicht vergessen. Die Verwaltung der Passkeys und deren Verwendung auf der richtigen Website übernimmt 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 ein 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 Merkmales, 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 Website 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 keinster 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 Anmelde-Rä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 sicher zu gehen, sollte man sich eine rechtliche Beratung einholen.

Cloud oder nicht Cloud!?

Ein zentraler, wenn auch nicht unbedingt notwender Bestandteil der Passkey-Spezifikation ist der, der 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. Oder!?

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 aus beiden 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 das selbe Cloud-Konto synchronisieren. Das machen die 3 großen Anbieter Apple, Goole und Microsoft heute schon und wir profitieren davon. Je nach Art und Größes unseres Arbeitgebers, exisitieren 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 verschlüsselt, dass nur der/die Besitzer:in an die Daten kommt, niemand anders, auch nicht der Cloud-Provider. Ja, wir müssen hier dem Anbieter vertrauen. Sicherheit hat (aber) immer 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 das gleiche Clound-Konto. Eine Cloud-übergreifende Synchronisation, also zwischen Cloud verschiedener Anbieter, ist (noch?) nicht vorgesehen.

Mit “ohne” Cloud und gemischte 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) 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.” (aus: Wikipedia, Client To Authenticator Protocol, abgerufen am 28.09.2023)

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 URI mit dem Schema FIDO:/... (siehe CTAP-Spezifikation, Kapitel 11.5.), zeigt diese URI in einem QR-Code verpackt an.

Der Authentifikator scannt den QR-Code und bekommt damit die Informationen, für welche Website (Domain) eine Anmeldung erforderlich ist. Der Authentifikator ermöglich 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 Merkmals. 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. gleiches 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 ich eine Verbindung zu einer Cloud benötige. 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. Diesen Hardware-Sicherheitsschlüssel steckt man in den USB-Steckplatz am Rechner. Browser, die Passkeys, bzw. WebAuthn 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 mal 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 rumtragen 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 (natürlich) auch wieder über eine Cloud. Hier kommt dann der gleiche Vertrauens-Anspruch 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.

Mozilla’s Firefox unterstützt zwar den WebAuthn Standard und Passkeys über Hardware-Sicherheitsschlüssel, kann aber selbst derzeit noch keine Passkeys generieren und verwalten. Eine Unterstützung ist angeblich bis Ende 2023 geplant, eine verlässliche Quelle dazu konnte ich jedoch nicht finden.

Wie die Lage bei Ubuntu Linux aussieht, ist derzeit nicht ganz klar. Einige Websites schreiben etwas davon, dass es möglich wäre, andere davon, dass nur bestimmte Browser unter Linux Passkeys anbieten und wiederum andere, dass es, wie bei Firefox, nur mit Hardware-Sicherheitsschlüsseln funktioniert. Die Website passkeys.dev zeigt eine Device Support Matrix, in der Ubuntu noch ziemlich wenig Unterstüzung aufweist.

Für Entwickler gibt es ebenfalls auf passkeys.dev eine Seite mit Bibliotheken, welche für unterschiedliche Programmiersprachen bereits Implementierungen zur Verfügung stellen. Unter Test Sites & Tools stehen Links zu Testseiten und Werkzeugen zur Verfügung, auf denen jeder seine Umgebung, Betriebssysteme und Browser testen kann. Die offiziellen Spezifikationen sind bei der FIDO Alliance zu finden.

Bei öffentlichen Websites sind technologie-affine Unternehmen und Plattformen, wie z.B. PayPal und GitHub, vorne mit dabei, wenn es um eine Passkey-Unterstützung geht. Andere Websites ziehen früher oder später nach, bzw. müssen nachziehen. Überraschenderweise findet man hier und da auch kleinere Unternehmen, die bereits eine Authentifizierung über Passkeys anbieten.

Wer Keycloak 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, diesen wiederherzustellen. Selbst in den Clouds soll dieser nur für den Besitzer 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 mit schwächste Methode, ist die, des Passwortes als Ersatz für den Passkey. (Bessere) Alternativen gibt es aber sicherlich, von der Nutzung von MagicLinks, 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änen-gebunden, 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.

Mit entscheident 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!