Das Login mit Benutzername und Passwort gibt es schon, seit es Computersysteme gibt. Etwa gleich alt sind auch die Probleme und Konflikte rund um diese Form der Authentisierung.
- Mit Blick auf die Sicherheit des Verfahrens muss ein Passwort einerseits möglichst lang sein und andererseits eine möglichst hohe Entropie aufweisen – also ein hohes Mass an Zufälligkeit durch eine möglichst beliebige Sequenz von Bits.
- Aus Benutzersicht soll das Passwort jedoch möglichst einprägsam sein – also möglichst kurz und einfach.
Um dieses Risiko zu minimieren, werden mehrere Authentisierungsfaktoren kombiniert.
- Knowledge: «Something you know» (z.B. Passwort, PIN)
- Ownership: «Something you have» (Smartcard, Mobiltelefon)
- Inherence: «Something you are» (biometrische Verfahren)
Klassische Vertreter der Mehrfaktor-Authentisierung in Kombination mit Knowledge (also etwa mittels Passwort) sind Smartcards (Chipkarten). Diese sind hinsichtlich der Sicherheit, aber auch für den Endbenutzer eine ideale Lösung. Die Problematik von Smartcards ist jedoch, dass deren Einführung und Unterhalt mit hohen Kosten verbunden ist (durch Einsatz einer Public Key Infrastructure - kurz PIK, Erfassen und Auslesen von Smartcards, kompatible Clients, Zertifikate, etc.).
Eine einfache und kostengünstige Kombination von Knowledge und Ownership läuft über das bestehende Passwort und den Besitz eines auf den Benutzer registrierten Smartphones. Bei erfolgreicher Authentisierung über das Passwort wird z.B. eine Textnachricht mit einem Einmalpasswort an die registrierte Smartphone-Nummer übermittelt, die der Benutzer als zusätzlichen Faktor bestätigen muss. Deutlich komfortabler ist die Zwei-Faktor-Authentisierung über eine entsprechende App auf dem registrierten Smartphone. Microsoft Azure Multi-Factor Authentication (Azure MFA) geht genau diesen Weg. Der Nachteil dieser Lösung ist, dass jede Applikation einzeln dafür integriert werden muss; zudem werden häufige Multi-Faktor-Authentisierungen als störend empfunden.
Windows Hello for Business (Windows Hello for Business) hingegen ermöglicht eine sichere Authentisierung schon beim Login am Client. Dabei wird ein «Windows Hello for Business Credential» erzeugt, das an das Trusted Platform Module (TPM-Chip) im Windows 10 Device (Ownership) gebunden ist. Als Zusatzfaktor wird eine sogenannte «Windows Hello for Business Gesture» eingesetzt. Das ist immer ein PIN (Knowledge) und optional biometrische Faktoren wie Fingerabdruck oder Gesichtserkennung.
Windows Hello for Business unterstützt wie Smartcards auch nicht Applikationen, sondern Identity Provider (IdP). Konkret unterstützt Windows Hello for Business alle IdP, die im Microsoft-Umfeld relevant sind:
- Azure Active Directory (AzureAD)
- Active Directory Federation Services (ADFS)
- Active Directory Domain Services (ADDS)
Die folgende Abbildung illustriert, dass dadurch grundsätzlich all jene Applikationen Windows Hello for Business unterstützen, die mindestens ein Protokoll der drei Microsoft IdPs unterstützen.
Um Windows Hello for Business zu nutzen, muss der Benutzer sich auf seinen Windows-10-Geräten registrieren. Dabei werden das «Windows Hello for Business Credential» (=Schlüsselpaar) auf dem Client erzeugt und die Windows Hello for Business Gestures gewählt, womit das «Windows Hello for Business Credential» geschützt wird. Für die Registrierung wird immer eine Mehrfach-Authentisierung verlangt (z.B. AzureMFA). Nach Abschluss der Registrierung haben Benutzer beim Login am Client die Wahl zwischen klassischer (via Kennwort) Anmeldung oder Anmeldung via Windows Hello for Business. Nutzt eine Person mehrere Geräte, so muss die Registrierung auf jedem zusätzlichen Gerät wiederholt werden. Ein Windows Hello for Business Gesture ist also nur auf jenem Gerät gültig, auf dem der entsprechende Benutzer registriert ist.
Die technischen Anforderungen, um Windows Hello for Business in Kombination mit Hybrid Deployment zu nutzen, sind verglichen mit Smartcards äusserst bescheiden:
- AzureAD Free
- Synchronisation ADDS - AzureAD
- Windows 10 Pro/Enterprise Device; registriert in AzureAD
- Genügend Windows Server 2016 Domain Controller Windows Hello for Business-Authentisierungen können nur von Windows Server 2016 und höher basierenden Domain Controllern verarbeitet werden.
- Azure MFA für die Registrierung
Wer also heute bereits Office365, AzureMFA und Windows 10 Pro/Enterprise Geräte einsetzt, ist schon bereit für die Einführung von Windows Hello for Business!
Weitere interessante Blogbeiträge
Eine bessere Möglichkeit, Ihr Netzwerk zu steuern
Einmaleins für Single Sign-on