Kombination von Smartcard und FIDO2 bei der Windows-Anmeldung, auch offline
Kombination von Smartcard und FIDO2 bei der Windows-Anmeldung, auch offline
Eine regionale öffentliche Organisation in Europa wandte sich mit ihrem Windows-Bestand an uns, der bereits durch Smartcard-Anmeldung gesichert war. Ihre Benutzer verwenden Smartcards und melden sich teilweise an Orten an, an denen kein Netzwerk vorhanden ist: Laptops, die das Gebäude verlassen und Stunden ohne Verbindung zu einem Authentifizierungssystem verbringen.
Beim Anmelden stellt Windows über seine Anmeldeinformationsanbieter verschiedene native Anmeldeinformationspfade bereit, darunter Kennwort, PIN, Smartcard und Windows Hello, und jeder für sich ist bereits eine starke Methode. Aber diese Pfade sind nicht dafür ausgelegt, beliebig in die exakte Reihenfolge verkettet zu werden, die diese Organisation wünschte: zuerst das Smartcard-Zertifikat, dann eine separate FIDO2-Zusage, keine zusätzliche erzwungene PIN für den Benutzer, der gesamte Ablauf funktioniert offline und eine kontrollierte MFA-Fallback-Option für den Fall, dass eine Karte verloren geht oder vergessen wird.
Jede dieser Anforderungen kollidiert mit einer anderen Annahme darüber, wie die Windows-Anmeldung funktioniert.
Warum FIDO2 hinzufügen, wenn eine Smartcard und eine PIN bereits zwei Faktoren sind?
Eine Smartcard-Anmeldung ist nicht schwach und erfüllt die klassische Definition der Multi-Faktor-Authentifizierung: etwas, das Sie haben, die Karte, und etwas, das Sie wissen, die PIN. Der Einwand ist also berechtigt: Warum noch etwas hinzufügen?
Die Antwort liegt darin, wohin die PIN geht. Eine für die Windows-Anmeldung verwendete Smartcard enthält in der Regel ein Benutzerzertifikat und den dazugehörigen privaten Schlüssel auf einem Hardware-token. Der Benutzer steckt die Karte ein, Windows liest das Zertifikat aus, und der Benutzer gibt eine PIN ein. Diese PIN wird niemals an einen Server übertragen; sie entsperrt die Karte lokal, sodass der private Schlüssel verwendet werden kann, um den Besitz des Zertifikats nachzuweisen. Was das Backend überprüft, ist die zertifikatsbasierte Authentifizierung, die durch den privaten Schlüssel auf der Karte gestützt wird, nicht die PIN selbst. Die PIN schützt diese einzelne Anmeldeinformation, anstatt einen zweiten, eigenständig überprüften Nachweis hinzuzufügen.
Diese Organisation wünschte sich eine zweite Authentifizierung, die eigenständig verifiziert wird und an die Person gebunden ist, statt nur an das token. Bei diesen tokens wird der FIDO2-Schritt durch einen Fingerabdruck auf dem token verifiziert, sodass die Anmeldung etwas kombiniert, das man besitzt (das token), etwas, das man weiß (die Smartcard-PIN) und etwas, das man ist (der Fingerabdruck). Damit wird die offensichtliche Lücke geschlossen: Eine Smartcard und eine gemeinsam genutzte oder offengelegte PIN reichen allein nicht aus, da für den FIDO2-Schritt weiterhin der registrierte Fingerabdruck erforderlich ist.
Einen zusätzlichen Faktor nach der Smartcard-Anmeldung hinzufügen, ohne die Karten zu ersetzen
OpenOTP, unser Authentifizierungsserver, fügt den Faktor auf dem bestehenden Smartcard-Anmeldevorgang über unseren Windows Credential Provider hinzu und arbeitet mit den bereits eingesetzten Karten zusammen, anstatt neue Hardware zu verlangen. Nach der Validierung des Smartcard-Zertifikats sendet er eine zweite Authentifizierungsanfrage für einen zusätzlichen Faktor: Eine Prüfung bestätigt das Zertifikat von der Karte, die andere validiert den hinzugefügten Faktor.
Im Projekt war der hinzugefügte Faktor FIDO2, mit WebADM, die zentrale Konsole, die die Dienste der Suite verwaltet und als die vertrauende Partei fungiert, die die FIDO2-Bestätigung verifiziert. Geändert wurde ein zweiter kryptografischer Beweis, der hinter der Smartcard liegt, für sich selbst verifiziert und von OpenOTP und WebADM-Richtlinie.
Die beiden Berechtigungen waren auf der Authentifizierungsebene voneinander getrennt, auch wenn sie in dieser Bereitstellung auf demselben physischen token gespeichert waren: Die Smartcards enthielten zudem die FIDO2-Anmeldeinformationen, sodass ein einziges token eine doppelte Funktion erfüllte. Das vereinfacht die Beschaffung und die Handhabung für die Benutzer, verändert aber auch die Vorgehensweise, wenn das token-Gerät verloren geht.
Ein PIN und ein Fingerabdruck, nicht zwei PINs
Ein token, das sowohl als Smartcard als auch als FIDO2-Authentifikator fungiert, kann bei der Anmeldung zwei PINs abfragen: zunächst die Smartcard-PIN zum Entsperren des Zertifikats und anschließend eine FIDO2-PIN zum Entsperren des Schlüssels. Zwei PINs bei jeder Anmeldung sind eine solche Hürde, die zu Beschwerden seitens der Nutzer führt und das IT-Team in die Defensive drängt.
FIDO unterscheidet zwischen zwei Aspekten: der „User Presence“ (Anwesenheit des Benutzers), also der physischen Berührung, die belegt, dass jemand anwesend ist, und der „User Verification“ (Benutzerauthentifizierung), einer PIN oder biometrischen Daten auf dem Schlüssel selbst. Diese können unabhängig voneinander verlangt werden. Da diese token-Schlüssel über einen Fingerabdrucksensor verfügen, wird die FIDO-Benutzerauthentifizierung durch einen Fingerabdruck anstelle einer zweiten PIN erfüllt. Der Benutzer gibt die Smartcard-PIN einmal ein und berührt dann den Sensor: eine einzige Geste, die sowohl die Anwesenheit nachweist als auch den Fingerabdruck auf dem token verifiziert. Es gibt keine zweite PIN, und die FIDO2-Antwort bleibt weiterhin phishing-resistent.
Ein zweiter Faktor, der zur Weiterarbeit offline beiträgt
Viele zweite Faktoren benötigen Konnektivität: eine OTP per E-Mail oder SMS, ein Push, ein Cloud-Anruf. Für Benutzer, die offline arbeiten, ist dies der Ausfallpunkt.
Der OpenOTP-Anmeldeinformationsanbieter wechselt automatisch in den Offline-Modus, wenn das Backend nicht erreichbar ist, und sowohl Smartcard als auch FIDO2 können in diesem Modus funktionieren. FIDO2 eignet sich dafür, da es auf asymmetrischer Kryptografie basiert: Sobald der Endpunkt bei einer früheren Online-Anmeldung "geseedet" wurde, beantwortet der Authentifikator eine Herausforderung und die Antwort wird lokal gemäß der Offline-Richtlinie überprüft.
Die Voraussetzung ist erwähnenswert, da sie die Auslieferung beeinflusst: Die Offline-Nutzung erfordert mindestens einen vorherigen erfolgreichen Online-Login pro Benutzer und pro Maschine, wodurch die Offline-Daten auf dem Endpunkt initialisiert werden. Danach führt ein Benutzer auf einem getrennten Laptop die gleiche Karten- und Touch-Anmeldung durch, die er auch im Netzwerk durchführen würde.
Deshalb erfüllt FIDO2 die Offline-Anforderung, wo ein per E-Mail oder SMS gesendeter Code dies nicht könnte: es kann am Endpunkt verifiziert werden, ohne etwas zu erreichen.
Was passiert, wenn ein Nutzer die Smartcard verliert oder vergisst?
Da eine token-Karte sowohl das Zertifikat als auch die FIDO2-Anmeldeinformationen enthält, gehen bei Verlust oder Vergessen der Karte beide Faktoren auf einmal verloren, was ohne Fallback zu Sperrungen führt, die vom IT-Team behoben werden müssen. Genau für diesen Fall ist der Fallback vorgesehen.
Ein zweiter Anmeldeinformationsanbieter befindet sich auf dem Endpunkt, neben dem für Smartcards. Wenn die Karte fehlt, wählt der Benutzer die andere Kachel aus und authentifiziert sich mit Benutzername und Passwort, aber der Fallback ist immer noch mehrstufig: Das Passwort allein reicht nicht aus, und der Benutzer muss einen Notfall-Einmalcode abschließen, der über die OpenOTP Token-App oder per E-Mail übermittelt wird. Der Weg über die Smartcard bleibt der Standard. Da ein übermittelter Code eintrifft, ist diese Wiederherstellungsroute online, im Gegensatz zum Offline-Pfad mit Karte und FIDO2.
Was diese Windows-Smartcard-MFA-Einrichtung dem Benutzer und dem Administrator bietet
Der Benutzer erhält eine Windows-Anmeldung, die nach einer PIN und einem Fingerabdruck fragt, auf einem getrennten Laptop genauso funktioniert wie im Netzwerk und ihn trotzdem hereinlässt, wenn seine Karte fehlt. Die Smartcard-Anmeldung wird beibehalten, mit einem separaten Faktor, der für sich allein verifiziert und an die Person gebunden ist, und die Identität bleibt lokal.
Für den Administrator werden die Faktoren, das Offline-Verhalten und der Fallback als Richtlinie in WebADM geregelt – der Konsole, über die bereits der Rest der Suite ausgeführt wird –, und es mussten keine neuen Karten oder tokens ausgestellt werden, um den zweiten Faktor hinzuzufügen.
Weiterführende Literatur
- Windows-Anmeldung & RDS: https://www.rcdevs.com/solutions/windows/
- Login & NAC mit PKI: https://www.rcdevs.com/solutions/pki/
- FIDO2-Authentifizierung https://www.rcdevs.com/solutions/fido2/
- Lizenz und Funktionen: https://www.rcdevs.com/license-features/
Eine Smartcard und eine PIN entsprechen der klassischen Definition der Multi-Faktor-Authentifizierung, doch die PIN entsperrt die Karte lediglich lokal und schützt nur einen einzigen Zugangsdatensatz. Durch die Ergänzung um eine FIDO2-Authentifizierung mittels Fingerabdruck wird eine zweite, an die Person gebundene Bestätigung eingeführt: Der Anmeldevorgang kombiniert nun etwas, das man besitzt (das „token“), etwas, das man weiß (die PIN) und etwas, das man ist (den Fingerabdruck), sodass eine offengelegte PIN allein keinen Zugriff gewährt.
Der Windows-Anmeldeinformationsanbieter von OpenOTP sendet eine zweite Authentifizierungsanfrage, nachdem das Zertifikat validiert wurde, und arbeitet mit den bereits eingesetzten Karten anstatt mit neuer Hardware. In diesem Projekt war der hinzugefügte Faktor FIDO2.
Beide Faktoren funktionieren im Offline-Modus des Credential Providers, der aktiviert wird, wenn das Backend nicht erreichbar ist. Die Offline-Nutzung erfordert mindestens eine vorherige Online-Anmeldung pro Benutzer und pro Maschine, um die Offline-Daten zu laden.
Die FIDO-Benutzerauthentifizierung kann entweder über eine PIN oder biometrische Daten erfolgen. Da diese token-Geräte über einen Fingerabdrucksensor verfügen, wird der FIDO2-Schritt mittels Fingerabdruck anstelle einer zweiten PIN verifiziert, sodass die Smartcard-PIN die einzige PIN bleibt.
Ein zweiter Anmeldeinformationsanbieter ermöglicht es dem Benutzer, sich mit Benutzername und Passwort plus einem einmaligen Notfallcode über die OpenOTP Token-App oder per E-Mail anzumelden, sodass die Fallback-Lösung weiterhin Multi-Faktor-Authentifizierung und nicht nur ein Passwort ist. Da der Code zugestellt werden muss, benötigt dieser Weg eine Verbindung.
Der Faktor wird On-Premise über den Windows Credential Provider hinzugefügt, wobei FIDO2 von WebADM als Relying Party verifiziert wird. Die Identität verbleibt On-Premise.
