Journey To Passwordless: Aber warum?

Einleitung

Über das Thema passwordless Authentication wird im Microsoft Kosmos aktuell viel gesprochen und geschrieben.

Doch was bedeutet es im Alltag den eigenen Account ohne Passwort zu nutzen?
Welche Vorraussetzungen müssen erfüllt sein und welche Einschränkungen bringt dies mit sich?

In dieser Blogserie möchte ich euch einen Überblick über den aktuellen Stand der vorhandenen Technologien geben und diese Schritt für Schritt erschließen.

Artikelübersicht

1. Passwordless - Aber warum?
2. Initiale Konfiguration
3. Temporary Access Pass
4. FIDO2 Security keys
5. Windows 10 Device Onboarding und Windows Hello for Business
6. Administrieren mit PowerShell und ohne Passwort
7. Microsoft Authenticator app
8. FIDO2 Schlüssel einschränken & Fazit

Warum ohne Passwort?

Die erste Frage die sich aufdrängt: Warum sollte ich auf das Passwort verzichten?

Passwörter sind schon immer die größte Sicherheitslücke in jeder Authentifizierung. Sie werden bei jeder Anmeldung über das Internet gesendet, von den Benutzern bei verschiedenen Diensten wiederverwendet oder zu einfach gewählt. Die Schuld bei den Benutzern zu suchen ist ein beliebter Reflex, doch zu kurz gedacht. Der Anwender möchte arbeiten können, die Sicherheitsanforderungen sind dabei meist nur hinderlich.

Passwortmanager bieten eine gute Möglichkeit die immer größere Anzahl an Logindaten zu verwalten. In einer Enterprise IT sollte die Lösung aber eine Identität, angebunden an eine zentrale Identity und Access Management (IAM) Lösung, sein. Entra ID (Azure AD) bietet mit den vorhandenen Schnittstellen und der langen Liste an direkt unterstützten Apps eine super Lösung.

Angriffe auf die Identitäten und “leichte” Kennwörter müssen dabei durch Conditional Access und Multifaktor Authentication (MFA) minimiert und erschwert werden.

Das Grundproblem der Passwörter lösen aber auch die aktuellen Techniken für MFA nicht. App Notifications, Token eingeben oder FIDO2 Security Schlüssel erhöhen die Sicherheit enorm, vereinfachen aber dem Anwender nicht die Anmeldung und das Kennwort wird immer noch über das Netzwerk übetragen.

Die einzige Lösung das Passwort nicht mehr zu übertragen ist es also Passwörter gar nicht erst zu verwenden.

Wie funktioniert eine Passwortlose Anmeldung

Im Gegensatz zu einer passwortbasierten Authentifizierung, setzt die passwortlose Authentifizierung auf Techniken, die so ähnlich schon lange Zeit für zertifikatsbasierte Authentifizierung genutzt werden. Der “Schlüssel” zum Erfolg liegt in der Nutzung von asymmetrischer Kryptographie und der, für den Benutzer, stark erleichterten Ausstellung der dabei benötigten Schlüsselpaare.

Das Entra ID (Azure AD) unterstützt aktuell drei Varianten der passwortlosen Authentifizierung:

• Windows Hello for Business
• Microsoft Authenticator app
• FIDO2 security keys

In allen drei Szenarien muss der Benutzer das entsprechende Geräte bzw. die Software mit dem eigenen Benutzer im Entra ID (Azure AD) verbinden. Dabei wird ein privater und öffentlicher Schlüssel generiert, wobei nur der öffentliche Schlüssel im Entra ID (Azure AD) gespeichert wird. Der private Schlüssel wird im TPM Chip des Computers (Windows Hello), auf dem Smartphone oder in der “secure enclave” des FIDO2 Schlüssels gespeichert.

Bei der eigentliche Anmeldung am Entra ID (Azure AD) wird, und diese Erklärung ist stark vereinfacht, immer folgendes Muster durchlaufen:

1. Der Authentication Provider auf dem Client sendet beim Anmeldevorgang eine Anfrage an das Entra ID (Azure AD)
2. Das Entra ID (Azure AD) beantwortet diese Anfrage mit einer zufälligen und willkürlich gewählten Zahl, der Nonce
3. Der Client signiert diese Nonce mit dem privaten Schlüssel. Dabei ist es wichtig, dass der private Schlüssel erst mittels einer PIN oder biometrischen Methode (Gesichtserkennung oder Fingerabdruck) freigegeben werden muss.
4. Nachdem die nonce signiert ist wird Sie wieder an das Entra ID (Azure AD) gesendet.
5. Das Entra ID (Azure AD) verifiziert die Signatur mit dem öffentlich Teil des Schlüssels und vergleich die Nonce.
6. Wenn die Nonce gültig und nicht älter als 5 Minuten ist, antwortet das Entra ID (Azure AD) mit einem primary refresh token (PRT)
7. Mit diesem PRT kann der Anwender nun auf Dienste wie Mail oder Teams zugreifen

Diese Darstellung ist, wie schon beschrieben, stark vereinfacht. Je nach genutzter Variante sind noch mehr Schritte notwendig und auch der PRT wird nicht direkt für den Zugriff auf Outlook genutzt.

Aber diese Darstellung zeigt eines sehr gut. Zu keinem Zeitpunkt wurde ein Kennwort übermittelt.

Die Nonce wechselt bei jeder Anmeldung und der private Schlüssel ist besonders geschützt nur auf dem Gerät des Benutzers gespeichert.

Wer einen tieferen Einblick in die Funktionweise der Authentifizierung des Entra ID (Azure AD) möchte, dem empfehle ich die wirklich sehr guten Videos von Stuart Kwan zum Thema Entra ID (Azure AD) Authentication Fundamentals.

Aber ist eine PIN nicht auch ein Passwort?

Nein, nicht im Sinne einer Authentifizierung mittels Benutzername und Passwort. Sie verlässt das Geräte des Benutzers nie und für ein besseres Benutzererlebnis kann Sie durch eine biometrische Methode ersetzt werden.

Aber für den Endanwender fühlt es sich, wenn kein Fingerabdruck genutzt werden kann, natürlich trotzdem wie ein Passwort an.

Nächste Schritte und das Ziel

Ziel dieser Blogserie ist in einer Microsoft Umgebung als Administrator 100% passwordless zu arbeiten. Um dieses Ziel zu erreichen werden auch Technologien, die sich aktuell noch in Preview befinden, genutzt.

Daher eignet sich diese Blogserie, auf jeden Fall nach meinem aktuellen Wissen, nur für erfahrene Anwender oder noch besser die Admnistratorenaccounts.

Im nächsten Blog werde ich die notwendigen Einstellungen im Entra ID (Azure AD) vornehmen um eine passwordless Authentication überhaupt nutzen zu können und mittels Conditional Access Policies die Anmeldungen von Administratoren zusätzlich absichern.