Vergessene Kennwörter selbst zurücksetzen

In diesem Beitrag möchte ich Euch mein Konzept zum Kennwortselbstreset für Windowsdomänen vorstellen.

Mit diesem Verfahren wird erreicht, dass Nutzer in Windowsdomänen (on-premises), wenn Sie Ihr Kennwort vergessen sollten, dieses jederzeit selbst zurücksetzen können, ohne auf die Verfügbarkeit eines Helpdesks angewiesen zu sein. Es ist ebenso nutzbar für PIN-Rücksetzung bei SmartCard-Nutzung. Umgesetzt wird es mit Skripten, welche ausschließlich Windows-Bordmittel nutzen.

Ich werde in diesem Beitrag weniger auf die technischen Einzelheiten der Umsetzung eingehen, sondern vielmehr darstellen, welche großen Unterschiede zu anderen kommerziellen Lösungen bestehen, die es bereits auf dem Markt gibt. Ich finde es sehr wichtig, in sicherheitsrelevanten Bereichen mit Software zu arbeiten, die so transparent wie möglich ist und denke, das ist mit dieser Methode gelungen. Wenn Ihr nach der Lektüre des Beitrags Interesse an der Methode habt, könnt Ihr Euch bei mir per PN melden, denn ich beabsichtige sie zum Kauf anzubieten. Preislich soll das Ganze unter den meisten Konkurrenzprodukten bleiben.

Um zu verdeutlichen, was das Konzept ausmacht, starte ich mit einem Einblick in die Arbeitsweise anderer Produkte aus der Gattung Self-Service Password Reset (im Weiteren „SSPR“, vergleiche Self-service password reset - Wikipedia).

Vergisst jemand sein Kennwort, so meldet er sich normalerweise beim Helpdesk. Der Helpdesk wird ihn als Person erkennen; beispielsweise ist das Aussehen persönlich bekannt, oder der Nutzer legt seinen Mitarbeiterausweis vor. Erst danach sollte der Helpdesk keine Bedenken haben, ein neues Kennwort zu setzen.

Um diesen Prozess automatisiert abzubilden und gleichzeitig vollständig autark vom Nutzer bedienbar zu machen, sind für jedes denkbare SSPR-Konzept drei Dinge nötig:

• Eine Art Ausweis, also etwas, was der Nutzer besitzt oder weiß, was kein anderer besitzt oder weiß
• Eine Art Ausweiskontrolle durch einen Kontrollserver, also eine technische Instanz (oft ein Webserver), die entscheiden kann, ob der Ausweis in Ordnung ist
• Ein automatisierter Rücksetzprozess, der nach erfolgreicher Ausweiskontrolle angestoßen wird.

Viele Produkte gehen hierbei wie folgt vor:

Beim Enrollment ("Ausweiserstellung") legt die Nutzerschaft fest, wie die eigene Identität nachgeprüft werden soll, beispielsweise durch die Beantwortung von individuell gewählten Sicherheitsfragen. Alternativ werden Authentifizierungsapps auf den Privatgeräten eingerichtet, oder OTP-Generatoren ausgegeben, es ist also nicht selten zusätzliches Equipment nötig. Im Enrollment werden auch die Wege zur Kommunikation festgelegt (z.B. E-Mailadresse, Handynummer um neue Kennwörter oder Challenge-Response-Codes auszutauschen).

Die Ausweiskontrolle erfolgt oft an einem über das Internet zugänglichen Webserver, denn das eigentliche System im LAN kann der Nutzer, ohne dass ihm sein Kennwort bekannt ist, nur noch eingeschränkt oder gar nicht nutzen.

Der Rücksetzprozess, üblicherweise angestoßen von dem System, welches die Kontrolle durchführt, läuft natürlich letzten Endes auf einem Domänencontroller ab. Der Kontrollserver hat somit das Privileg, dem Domänencontroller Befehle zu geben (!).

Meine Motivation dazu, selbst ein ähnliches System zu entwickeln, entstand nach einer Betrachtung der prinzipbedingten Schwächen einiger gängiger SSPR-Produkte. Alle diese Schwächen beziehen sich auf die Sicherheit, denn mit Sicherheit sollte ein SSPR einem Angreifer nicht in die Karten spielen, sprich:


Das führt zur interessanten Frage:
Kann man die Sicherheit von verschiedenen SSPR-Verfahren nachvollziehbar bewerten und vergleichen?

Ich will es versuchen und zumindest zum Nachdenken anregen anhand von Gedanken zu Komponenten von "herkömmlichen" Systemen:

• Dass Sicherheitsfragen nicht sonderlich sicher sind, ist schon lange bekannt. Studien haben ergeben, dass beispielsweise enge Freunde oder (Ex-) Lebenspartner die korrekte Antwort auf diese Fragen mit einiger Wahrscheinlichkeit (Einzelfrage bis zu 40%) geben könnten, oder diese Antworten gar recherchierbar sind. Schaltet man, um dem entgegenzuwirken, gleich mehrere Sicherheitsfragen hintereinander, erhöht man das Risiko, dass selbst der legitime Nutzer die Antworten auf diese Fragen nicht korrekt wiedergeben kann, da er sie nicht vollständig erinnert oder sich vertippt. NIST beispielsweise rät aus diesen Gründen von der Verwendung von Sicherheitsfragen ab.
• Alternativ genutzte technische Hilfsmittel jeglicher Art erhöhen die Komplexität. Der Nutzer muss zum Beispiel einen Codegenerator stets mit sich führen oder eine passende Authenticator-App auf dem Smartphone installiert haben. Wie schätzt man deren Sicherheit ein, besteht da überhaupt Transparenz? Ich denke nein.
• Der Kontrollserver hält das Privileg, dem Domänencontroller Kennwort-Rücksetzungen aufzutragen. Das bedeutet in Konsequenz, dass er sicherheitstechnisch denselben Schutzbedarf hat, wie dieser, also “höchstmöglich”. Wenn dieses System jedoch Internetzugang haben muss (LAN reicht ja nicht, denn aus dem LAN sind wir ohne Kennwort ja ausgesperrt), wird es schwierig, das noch als “höchstmöglich geschützt” zu bezeichnen. Wird dieser Server gehackt, ist das ähnlich kritisch zu sehen, wie ein gehackter Domänencontroller.
• Betrachten wir auch die Nutzerseite. Einige Systeme ermöglichen dem Nutzer, das neue Kennwort selbst festzulegen (=einzutippen)… auf seinem Privatgerät. Wer möchte garantieren, dass dieses System nicht kompromittiert ist?

Für mich sind das Risiken, ja eine Hintereinanderschaltung von Unwägbarkeiten. Auch möchte ich mit Sicherheit nicht in diesem sensiblen Bereich mit Systemen arbeiten, die am Internet hängen. So kam es, dass ich mich um eine eigene Lösung dafür gekümmert habe, die mir zusagt.

Ich möchte nun herausstellen, was an meinem System besonders ist.

Mein Ansatz funktioniert wie folgt:

Beim Enrollment gibt der zuvor authentifizierte Nutzer lediglich seine private Mailadresse (oder wahlweise Handynummer), seinen Nutzer- sowie seinen PC-Namen an (nur an diesem einen PC wird die Rücksetzung möglich sein!) und bekommt nach Prüfung dann ein zufälliges Codewort mitgeteilt, was er sich merken muss. Dieses Codewort ist also ein echtes Wort aus einem großen Lexikon und im Rahmen des Verfahrens gesichert gegen Brute-Force-Angriffe. Zur Veranschaulichung:


Die Rücksetzung ist am hochgefahrenen Firmen-PC ohne Anmeldung möglich. Zugang zur Anmeldemaske ist alles, was wir brauchen.

• alle Nutzereingaben erfolgen hierbei auf dem Firmen-PC unter Zuhilfenahme der Anmeldemaske
• Es wird kein zusätzlicher schützenswerter, privilegierter Server nötig, sondern der DC selbst nimmt die Rolle des Kontrollservers an. Internetzugang benötigt dieser nicht!
• Die Identitätskontrolle findet via 2-Faktor-Authentifizierung statt, erster Faktor: das Codewort, zweiter Faktor: der Zugang zu dem registrierten Mailpostfach (oder SMS). Es würde vom Nutzer erwartet, dass er dafür ein SmartPhone mit sich führt.
• Die im Rücksetzprozess via SmartPhone (Mail oder SMS) abgerufenen Informationen sind nur kurzfristig und gerätegebunden nutzbar, ein Missbrauch ist so selbst bei Kompromittierung des SmartPhones oder Mailpostfaches ausgeschlossen!

Zur Veranschaulichung kommen hier Screenshots des Ablaufs. An der Anmeldemaske kann bei Bedarf ein Hinweis gegeben werden, wie es funktioniert:

Hier im Beispiel heißt der Nutzer, der sein Kennwort vergessen hat, "Forgot" und sein Codewort lautet „Gurke“.


Die Wiederherstellung findet direkt am Anmeldescreen des registrierten PCs statt.
Das Codewort (Gurke) wird als Nutzername eingeben, die Kennwortzeile wird leer gelassen, [Enter}:


Das System meldet daraufhin lediglich „Nutzername oder Kennwort falsch“, aber im Hintergrund wurde automatisch ein Prozess ausgelöst, der prüft:
->Ist Gurke ein Codewort? Ja!
->ist dieses Codewort auf dem dafür registrierten PC verwendet worden? Wenn ja, wird eine E-Mail an die damit verknüpfte Adresse gesendet, die so aussieht (der String wird jedesmal zufallsgeneriert):


Das tut der Herr Forgot dann auch:


Wieder heißt es nur „Nutzername oder Kennwort falsch“ doch im Hintergrund wurde dadurch die Authentifizierung komplettiert (der Nutzer hat durch die Angabe des Zufallsstrings aus der Mail nachgewiesen, dass er auch an den zweiten Faktor, das Mailpostfach, rankommt) und nun wird nach wenigen Sekunden ein neues Kennwort per Popup eingeblendet:


Wieder gibt man den Inhalt des Popups ein… diesmal allerdings als Kennwort für Nutzer „forgot“
…Spannung…


Resultat: man darf nun (in gewohnter Windows-Manier) sein Kennwort ändern.


Der Rest ist klar:



Fertig! Der gesamte Vorgang hat weniger als 2 Minuten gedauert.
[Zur Erinnerung: an dieser Stelle hätte auch der PIN-Wechsel einer SmartCard erfolgt sein können]

Sicherheitsbetrachtung:
Ich habe bei dem Verfahren darauf geachtet, dass die Systeme (Clients und Domänencontroller) nicht komplexer gemacht werden:

• keine zusätzlich geöffneten Ports
• keine Agents
• keine Hilfssoftware wie Frameworks
• den Systemen werden keine Dienstkonten hinzugefügt

Die somit gebotene Angriffsfläche ist reduziert auf die Eingabemöglichkeit eines korrekten Codewortes. Brute-Force ist hierbei ausgeschlossen.

Betrachtet man die Sicherheit des Codewortes gegen tatsächliches glückliches Erraten, so hängt die Einbruchschance von der Größe des Wörterbuches ab (das Wörterbuch könnt Ihr frei konfigurieren).

Beispiel: der Angreifer vermutet, dass als Codewort nur deutsche Nomen verwendet werden. Das wären dann mehr als 10.000 Wörter. Aber der Angreifer hat lediglich einen Versuch, Rumprobieren wurde unmöglich gemacht. Es ergibt sich eine Erfolgswahrscheinlichkeit von kleiner als 1:10.000 für den Angriff und das ohne die weiteren Absicherungen (Gerätebindung, Schutz des Mailpostfaches) mit einzurechnen.

Aus diesen Gründen hätte ich keine Bedenken dabei, das Verfahren auch bei sicherheitskritischen Konten zu aktivieren, zumal im Verfahren auch misslungene Angriffe sofort gemeldet werden.

Diese Betrachtung geht davon aus, dass der Nutzer in der Lage ist, sein Codewort zu erinnern, ohne es auf dem berühmten Zettel unter der Tastatur notiert zu haben.

Technische Voraussetzungen:
Windows-Domänencontroller: Server 2016/2019/2022/vNext getestet.
Der DC benötigt keinen Internetzugang, muss aber Zugang zu einem Mail- oder Messenger- (z.B. Exchange- oder SMS-) System haben.
Clients: Windows 10/11 getestet. Es ist eine LAN- oder (always-on) VPN-Verbindung nötig. Die Clients selbst benötigen keinen Internetzugang.
Die Mitarbeiter müssen zudem E-Mails oder SMS abfragen können (Smartphone/Tablet).
Bei SmartCard-Nutzung: getestet mit Yubikey 5 und Safenet ID Prime.

Nochmals: wer ein Kaufinteresse hat, melde sich gerne per PN
Wenn Fragen zum Verfahren bestehen, werde ich diese hier beantworten.