Breached Passwords / autom. Prüfung?

[Garant 3]

Guten Morgen,

 

habt Ihr Anwendungen für die autom. Prüfung von Breached Passwords  (z.B. gegen haveivebeenpwned) im Einsatz? Und wenn ja, was für Anwendungen/Skripte oder Lösungen setzt Ihr ein?

Ich habe unter https://www.alitajran.com/secure-active-directory-passwords/ ein Skript gefunden, welches die Passwörter im Active-Directory dagegen prüft und zusätzlich eine GPO bereitstellt, die bei der Auswahl des Kennworts dies auch berücksichtigt.

 

Die Frage ist nur, für wie sicher haltet Ihr die Integration o.g. Skripts? Oder gibt es dafür auch "professionelle" Anbieter?

 

Gruß

[NilsK 2.785]

Moin,

 

zunächst einmal prüft das Skript nicht die Kennwörter im AD. Das kann es auch gar nicht, denn die Kennwörter sind dort gar nicht gespeichert, nur deren Hashes. Das Skript schaut, ob die Accounts in "Breaches" aufgetaucht sind. Wie wahrscheinlich das bei internen AD-Accounts ist, mag man sich selbst zusammenreimen.

 

Die Kennwörter aus der Liste werden herangezogen, wenn ein User sich ein neues Kennwort gibt. Das ist die klassische "Filter"-Funktion. Ich bin grundsätzlich ein Freund von sowas, aber hauptsächlich dann, wenn Standard- und Lulli-Kennwörter vermieden werden sollen. Ob man dazu diese Liste braucht ... man muss sich dabei auch vor Augen führen, dass die übliche Reaktion bei der Zurückweisung eines Kennworts darin besteht, einzelne Zeichen anzuhängen. Die Sicherheit erhöht sich dadurch nicht.

 

Wie vertrauenswürdig das angesprochene Tool ist, weiß ich nicht. Man kann sowas machen, sollte sich aber auch nicht zu viel davon versprechen. Dasselbe gilt für Troy Hunts ganzes "Haveibeenpwned"-Projekt - das ist eher ein Awareness-Tool als eine Hilfe. Die konkreten Informationen, die man dort rausbekommt, sind typischerweise ziemlich nutzlos und oft irreführend (in nahezu allen Stichproben, die ich durchgeführt habe, ließ sich nachweisen, dass dort angeblich "gebreachte" Accounts bei dem "gehackten" Anbieter gar nicht existiert hatten).

 

Gruß, Nils

 

[mwiederkehr 351]

vor 17 Minuten schrieb NilsK:

zunächst einmal prüft das Skript nicht die Kennwörter im AD. Das kann es auch gar nicht, denn die Kennwörter sind dort gar nicht gespeichert, nur deren Hashes. Das Skript schaut, ob die Accounts in "Breaches" aufgetaucht sind. Wie wahrscheinlich das bei internen AD-Accounts ist, mag man sich selbst zusammenreimen.

Laut https://docs.lithnet.io/password-protection/advanced-help/powershell-reference/test-isaduserpasswordcompromised liest es die Hashes aus dem AD und vergleicht sie mit gehashten Passwörtern auf der Liste.

 

Aber sonst bin ich Deiner Meinung. Man sollte sich überlegen, in welchem Szenario "Passwörter durchprobieren" überhaupt realistisch ist. Wenn der Benutzer die Zugangsdaten auf einer Phishing-Seite eingibt, hilft ein komplexes Passwort nicht und man hat hoffentlich nicht RDP offen, sodass tausende Passwörter durchprobiert werden können. MFA ist inzwischen komfortabel genug geworden, um es für jegliche Zugriffe von extern zu erfordern. Damit verliert das Passwort nochmals an Bedeutung.

 

Aus meiner Sicht reichen die Komplexitätsanforderungen von Windows aus für normale Accounts. Und bei Admin-Accounts sollte man darauf vertrauen können, dass die Admins selbst ein genug sicheres Passwort verwenden.

[NilsK 2.785]

Moin,

 

vor 9 Minuten schrieb mwiederkehr:

Und bei Admin-Accounts sollte man darauf vertrauen können, dass die Admins selbst ein genug sicheres Passwort verwenden.

 

das lässt sich sogar recht einfach herstellen: Man erzeuge ein Password Settings Object, verknüpfe dies mit allen Admin-Gruppen und fordere dort ein langes Kennwort ein. Size matters.

 

Gruß, Nils

 

[cj_berlin 1.137]

Moin,

 

Azure AD hat übrigens auch eine solche Prüfung, die durchaus auch für synchronisierte AD-Accounts angewandt wird. Beim Passwortwechsel in AD freilich erst im Nachhinein, beim Passwortwechsel in AAD halt schon bevor das Passwort gesetzt wird. Aber die haben auch einen eigenen Filter-Agenten, den man für die Prüfung im AD, aber gegen die Listen aus dem Azure AD, einsetzen kann. Diesen würde ich im Zweifel als vertrauenswürdiger einstufen als eine Third Party.

 

Das generelle Problem bei ALLEN diesen Filter-DLLs ist, dass in Windows keinerlei API existiert, um dem Kontoinhaber mitzuteilen, WORAN GENAU sein Änderungsversuch gescheitert ist.

[Garant 3]

Moin,

 

vielen Dank schon einmal für die Anregungen. Das wirft auch nochmal ein anderes Licht auf die Fragestellung.

@NilsK - Es ist so, wie mwiederkehr geschrieben hat, dass nur die Hashs verglichen werden. Das im AD die Passwörter nicht im Klartext hinterlegt sind, ist mir auch bewusst.

 

Nach Außen ist für uns nicht "offen", nur die Anmeldung via Outlook WebApp und das bereitete Sorge.

[testperson 1.534]

Hi,

  

vor 4 Minuten schrieb Garant:

Nach Außen ist für uns nicht "offen", nur die Anmeldung via Outlook WebApp und das bereitete Sorge.

 

Sofern es tatsächlich nur OWA und kein EAS bzw. etwas mit Basic Auth ist, dann könnt ihr doch - wie @mwiederkehr vorschlägt - dort einen zweiten Faktor integrieren. Wenn EAS dabei ist, wäre HMA ein Ansatz oder ihr müsst warten, bis die MA auch in reinen On-Premises Umgebungen da ist.

 

Gruß

Jan