Hintergrund: Wenn man einige Zeit mit FIDO2-Security-Token experimentiert hat, wird einem schnell bewusst, welche Schwachstellen das derzeitige Konzept noch aufweist und welche Angriffsmöglichkeiten bestehen. Das wirft zugleich die Frage auf, wie der sinnvolle Umgang mit solchen Security-Token gestaltet werden sollte. Dass man sich nicht auf die bloße Existenz eines einzigen Nitrokeys verlassen sollte, dürfte spätestens nach der Lektüre der Dokumentation und weiterer Quellen jedem einleuchten.
Für mich stellt sich außerdem die Frage, ob man – je nach Anwendungszweck und Rolle der Security-Token – weitere Paare von Nitrokeys (oder Alternativen) vorsehen sollte. Ich denke dabei an eine strikte Trennung der Rollen, beispielsweise in folgendem Sinne:
- Je zwei Security-Token/Nitrokeys für wichtige Online-Konten im Bereich der Softwareentwicklung
- Je zwei Security-Token/Nitrokeys für den Zugang zu Maschine A (Login, Festplattenverschlüsselung usw.)
- Je zwei Security-Token/Nitrokeys für den Zugang zu Maschine B
- Je zwei Security-Token/Nitrokeys für eine weitere Online-Identität
- Je zwei Security-Token/Nitrokeys zur Absicherung einer Passwortdatenbank für alle nicht FIDO2-konformen Online-Konten
Der Hintergrund dieses Gedankengangs dürfte klar sein: Auch das Vorhandensein eines FIDO2-Security-Tokens bietet theoretisch keine hundertprozentige Sicherheit.
Zudem kann der Aufwand ziemlich ausarten, wenn man einen Key in mehreren Rollen verwendet und er - nehmen wir der Einfachheit halber an - sich nicht so verhält, wie es gewünscht ist (das Supportforum kann für diesen „Nichtanwendungsfall“ leider einige Beispiele liefern). Dann steht man vor einer Vielzahl an Abhängigkeiten mit unterschiedlichen Verhaltensweisen: Der Key wird für OpenPGP, FIDO2 und TOTP eingesetzt, das Verhalten der Software unterscheidet sich jedoch je nach Einsatzbereich, zum Beispiel beim Reset. Wird der Key beschädigt oder ist er aus anderen Gründen nicht mehr benutzbar, wird die Verwaltung schnell unübersichtlich. Außerdem bin ich bisher nicht wirklich sicher, dass der Flashspeicher außerhalb des Security Elements auf eine Art und Weise beschrieben wird, die den Speicher nicht zu schnell zerstört. Immerhin war diese Problematik anfangs selbst bei namhaften Herstellern von SSDs ein Thema.
Deshalb denke ich über einen Einsatz nach, bei dem dieser Baum der Abhängigkeiten nach Möglichkeit aus einer Wurzel (Token) und einigen zusätzlichen Blättern (Credentials) besteht. Das vereinfacht das Management im Fehlerfall erheblich.
Als Beispiel: Man besitzt ein Security Token (plus ein Backup-Token) für SSH auf diversen Maschinen; das Token ist für den Einsatz im Bereich SSH beschränkt. Wird ein anderes Security Token mit anderen Rollen unbrauchbar, ist zumindest dieser Abhängigkeitsbaum davon völlig unberührt, was den administrativen Aufwand im “Fehlerfall” deutlich reduzieren dürfte.
Insbesondere halte ich die Möglichkeit, mittels fido2-token -R <device> die Credentials eines Geräts zunichtezumachen, für einen gravierenden Konstruktionsfehler der Spezifikation in ihrer derzeitigen Form. Zwar wird gelegentlich argumentiert, diese Funktion sei mit dem Formatieren einer Festplatte vergleichbar. Diese Argumentationsweise halte ich jedoch für nicht überzeugend. Als Besitzer einer Festplatte kann ich geeignete Vorkehrungen treffen, etwa durch Backups, die es mir ermöglichen, einen Fehler oder sogar einen Angriff mit einem einzigen Kommando oder Programmstart rückgängig zu machen. Genau diese Möglichkeit besteht bei FIDO2-Security-Token jedoch nicht, da sie nicht für die lokale Nutzung, sondern für den Einsatz auf zahlreichen Online-Plattformen konzipiert sind. Ist ein solches Token plötzlich auf 100 Websites nicht mehr gültig, muss ich den Zugriff auf jede einzelne dieser Websites wiederherstellen. Somit stellt dieser Befehl nicht nur eine Schwachstelle des FIDO2-Systems dar, sondern macht es auch notwendig, sich Gedanken darüber zu machen, welche Security-Token in welcher Kombination und für welchen Zweck eingesetzt werden sollten. Das ist der Hintergrund meiner Frage. Ich hoffe daher auf möglichst viele erfahrungsbasierte Antworten.
Die Zahl 100 ist hierbei lediglich exemplarisch gewählt und entspricht nicht der tatsächlichen Kapazität eines Nitrokeys, auch wenn berichtet wird, dass andere Lösungen durchaus eine vergleichbare Anzahl von Zugängen unterstützen.
Um diesen Punkt noch einmal zu verdeutlichen: Auch wenn man sich Gedanken über einen möglichst sicheren Einsatz machen und mehrere Security-Token vorsehen sollte, halte ich physische Security-Token dennoch für die deutlich bessere Lösung gegenüber den derzeit diskutierten Passkey-Lösungen. Diese stellen allzu häufig Insellösungen dar und wirken nicht selten wie der Versuch großer Plattformanbieter, sich voneinander abzugrenzen. Interoperabilität wird dort häufig kleinergeschrieben als bei FIDO2. Hinzu kommt, dass Passkeys leicht in eine komplexe Verwaltungssituation führen können, in die man sich möglicherweise gar nicht begeben möchte. Dies nur als Randbemerkung.
Physische Security-Token sind rein softwarebasierten Passkeys aus meiner Sicht eindeutig vorzuziehen aufgrund der Einfachen Tatsache, dass man die in über 90 Prozent der Nutzungszeit physisch vom System trennen kann.
Mein derzeitiger Plan sieht daher eine klare physische Trennung der einzelnen Rollen durch zusätzliche Security-Token vor. Die dadurch entstehenden Kosten dürften allerdings für viele Privatanwender ein gewichtiges Argument dagegen sein. In diesem Bereich besteht aus meiner Sicht daher weiterhin erheblicher Entwicklungsbedarf.