Heutzutage verfügt jede Organisation über ein LDAP-Verzeichnis, das mit Benutzern dieser Organisation gefüllt ist. Wenn Sie genau hinsehen, finden Sie eine oder mehrere Anwendungen, die dasselbe Verzeichnis für die „Authentifizierung“ verwenden. Und die Anführungszeichen sind hier nicht zufällig, da LDAP ein Verzeichniszugriffsprotokoll ist, das zum Lesen, Schreiben und Durchsuchen des Verzeichnisdienstes entwickelt wurde. Dies ist kein Authentifizierungsprotokoll. Der Begriff „LDAP-Authentifizierung“ bezieht sich vielmehr auf den Teil des Protokolls (Bindevorgang), der festlegt, wer Sie sind und welche Zugriffsrechte Sie auf die Verzeichnisinformationen haben.
Im Laufe der Zeit hat sich LDAP zu einem De-facto-Authentifizierungsdienst entwickelt. Umfassende und kostengünstige LDAP-Dienste wie Active Directory sind ein Leckerbissen für Softwareentwickler, die Authentifizierung in ihre Produkte integrieren möchten. LDAP-Client-Bibliotheken sind für nahezu jedes Framework verfügbar und die Integration ist relativ einfach zu implementieren.
Trotz der Tatsache, dass die Verwendung von LDAP das Problem der Implementierung der Benutzerauthentifizierung in verschiedenen Anwendungen des Unternehmens lösen kann, treten viele Probleme auf. Im Gegensatz zu speziell entwickelten Authentifizierungsprotokollen führt die Verwendung von LDAP zu verschiedenen Sicherheitslücken in Bezug auf Informationen.
Um zu verstehen, wie diese Sicherheitsanfälligkeiten aussehen, müssen Sie zunächst die Funktionsweise der LDAP-Authentifizierung kennen.
Funktionsweise der LDAP-Authentifizierung
Stellen Sie sich die folgende Situation vor (sie ist weit von der Realität entfernt, vermittelt aber die Essenz perfekt).
Angenommen, ich platziere eine Bestellung in einem Online-Shop, damit sie in meiner Abwesenheit zu mir nach Hause geliefert wird. Der Kurier kommt an und hinterlässt eine Nachricht unter der Tür mit dem Text "Es tut mir leid, wir haben Sie nicht gefunden" und bittet mich, die Bestellung zu einem geeigneten Zeitpunkt an der nächsten Abholstelle abzuholen. An der Abholstelle fragt der Mitarbeiter nach meinem Namen, meiner Adresse und den Schlüsseln für das Haus, um meine Identität zu bestätigen. Dann kommt der Lieferservice zu mir nach Hause und öffnet die Tür mit meinem Schlüssel. Er geht hinein, um sicherzustellen, dass ich dort lebe, zum Beispiel anhand von Fotos an der Wand oder mit dem Namen des Empfängers auf der Korrespondenz. Danach kehrt der Mitarbeiter zur Ausgabestelle zurück und teilt mir mit, dass er meine Identität erfolgreich bestätigt hat und ich mein Paket erhalten kann! Hurra!
Neben logistischen Problemen gibt es in dieser Situation noch viele andere Probleme. Was ist, wenn ein skrupelloser Prüfer eine Kopie meines Schlüssels erstellt hat? Oder ließ er den Schlüssel lange Zeit unbeaufsichtigt und tat es jemand anderes? Was ist, wenn der Tester angegriffen und mein Schlüssel abgenommen wurde? Wenn ich einem Fremden den Schlüssel für meine Wohnung übergebe, kann ich nicht sicher sein, ob er anständig und sicher ist.
Glücklicherweise verfügen wir in der realen Welt über Ausweispapiere, z. B. einen Führerschein oder einen Reisepass, die von Regierungsbehörden ausgestellt werden, und deren Echtheit ist unbestritten. Ich kann diese Dokumente dem Kurier zur eigenen Identifizierung zur Verfügung stellen, ohne die Schlüssel zu übergeben.
In der LDAP-Welt müssen wir noch unsere Schlüssel übergeben, um die Tür für uns zu öffnen. Wir geben unser Passwort an Dritte weiter und er versucht, damit in den LDAP-Server einzudringen. Wenn er Zugriff erhält, können wir nicht sicher sein, dass unsere Anmeldeinformationen nicht gefährdet sind. In diesem Fall kann der Angreifer nicht nur die LDAP-Tür entsperren, sondern auch auf alle Anwendungen zugreifen, die dieselben Anmeldeinformationen verwenden.
Zum Glück haben wir in einer vollständigeren Welt der Authentifizierung auch Pässe und Führerscheine! Authentifizierungsprotokolle wie Kerberos, SAML und OpenID Connect stellen Token an Dritte aus. Tokens bestätigen, dass Sie derjenige sind, für den Sie sich ausgeben, und dass Sie Ihre Schlüssel an niemanden weitergeben müssen. Da LDAP nie als Authentifizierungsprotokoll konzipiert wurde, fehlen die entsprechenden Mechanismen.
Nachteile von LDAP als Authentifizierungssystem
2007 veröffentlichte Shumon Hack einen Science-Fiction-Artikel (
LDAP-Schwächen als zentrales Authentifizierungssystem ), in dem er drei spezifische Probleme bei der Verwendung von LDAP als Authentifizierungssystem beschreibt.
1. Die Anwendung ist wahrscheinlich nicht sicher genug, um Anmeldeinformationen zu verarbeiten
Der Autor betont, dass das Schützen einer kleinen Anzahl von Authentifizierungsservern vor Angriffen viel einfacher ist als das Schützen einer großen Anzahl von Anwendungsservern.
Authentifizierungsserver werden in der Regel von Spezialisten mit umfangreicher Erfahrung auf dem Gebiet der Informationssicherheit engmaschig überwacht.
Andererseits weisen Anwendungsserver ein völlig anderes Sicherheitsniveau auf und sind gefährdeter. Sie sind weniger sicher, arbeiten mit komplexeren Software-Stacks und weisen mit höherer Wahrscheinlichkeit Schwachstellen auf. Und häufiger werden sie von Personen verwaltet, die über keine umfassenden Sicherheitskenntnisse verfügen. Der Aufbau des richtigen Sicherheitssystems ist ein komplizierter Prozess, bei dem es sehr leicht ist, einen Fehler zu machen.
Das Problem ist, dass, wenn ein Anwendungsserver kompromittiert wird, alle Anmeldeinformationen, die von ihren Besitzern während des Angriffs verwendet werden, ebenfalls kompromittiert werden. Jedes andere System, das dasselbe LDAP-Verzeichnis für die Authentifizierung verwendet, ist gefährdet.
2. Der LDAP-Server kann den Authentifizierungsmechanismus zum Abrufen von Anmeldeinformationen nicht sichern
Ein LDAP-Server kann die Transaktionssicherheit nicht garantieren. Obwohl ein LDAP-Server beispielsweise die Bindung über TLS erzwingen kann, um sicherzustellen, dass Anmeldeinformationen nicht im Klartext übertragen werden, hat der Server selbst keine Rolle beim Abrufen von Anmeldeinformationen vom Benutzer gespielt. Es besteht die Gefahr, dass die Anwendung über einen unsicheren Kanal ein Kennwort erhält.
3. Der Benutzer ist gezwungen, sein Authentifizierungsgeheimnis an Dritte weiterzugeben
Benutzerkennwort oder Authentifizierungsgeheimnis müssen geheim bleiben. Es sollte nur dem Benutzer und dem Authentifizierungssystem bekannt sein. Bei der Verwendung der LDAP-Authentifizierung muss der Benutzer sein Geheimnis an einen Dritten weitergeben, damit er im Namen des Benutzers mit diesem Geheimnis mit dem LDAP-Verzeichnis interagieren kann.
Es ist wichtig zu erwähnen, dass bei der Verwendung von speziell entwickelten Authentifizierungsprotokollen wie Kerberos und sogar vom früheren NTLM das Geheimnis des Benutzers niemals über das Netzwerk übertragen wird. Das Client-Gerät und der Server verwenden kryptografische Operationen, um sich gegenseitig zu beweisen, dass sie dasselbe Geheimnis haben, und das Geheimnis selbst nicht einmal auszutauschen.
Zu den Punkten von Shumon Hook werde ich eine Beschreibung einiger Nuancen der LDAP-Authentifizierung hinzufügen, die auf meinen eigenen Erfahrungen basieren. Zunächst geht es um die Verwendung von Active Directory.
4. Viele Entwickler wissen nicht genug über LDAP-Mechanismen Bescheid, um sie korrekt zu verwenden
In einem meiner letzten
Blog- Beiträge wurde beschrieben, wie anonyme und nicht authentifizierte Bindungen Anwendungsentwickler überlisten und nicht autorisierte Benutzer zum Überspringen bringen konnten. Die Möglichkeit, einen Bindevorgang ohne Authentifizierung auszuführen, ist eine der Feinheiten des Protokolls, die selbst den erfahrensten LDAP-Experten nicht bekannt sind.
Verzeichnisse sind nicht einfach zu organisieren und können eine große Menge von Organisationsinformationen speichern und bieten viele anpassbare Möglichkeiten, diese zu speichern. In vielen Fällen ging der Anwendungsentwickler davon aus, dass eine bestimmte Objektklasse oder ein bestimmtes Attribut vorhanden ist, und als sie nicht erkannt wurden, stürzte die Anwendung ab. Für die Benutzerauthentifizierung sollte keine Kenntnis der Struktur der im Verzeichnis gespeicherten Daten erforderlich sein und angewendet werden. Das Authentifizierungsprotokoll sollte von den Details des Objekt-Repositorys auf einer niedrigeren Ebene abstrahiert werden.
5. Anwendungsadministratoren konfigurieren LDAP-Clients häufig nicht richtig
Beim Verwalten von Active Directory in einer großen verteilten Umgebung gibt es eine unangenehme Nuance: Es ist schwierig zu bestimmen, welche bestimmten Anwendungen Active Directory als LDAP-Verzeichnis verwenden und wie genau die Anwendungsadministratoren den LDAP-Client konfiguriert haben.
Das Folgende sind Beispiele für die Schrecken der Fehlkonfiguration.
- Festcodieren von DN in Anwendungen oder Verwenden von DN in einem Bindevorgang. Probleme treten ständig beim Umbenennen oder Verschieben von Objekten innerhalb eines Verzeichnisses auf, und das alles, weil jemand irgendwo einen fest codierten DN hat. (Hinweis für Benutzer, die einfache Bindevorgänge mit Active Directory ausführen: Es ist nicht erforderlich, einen DN zu verwenden. Active Directory bietet auch alternative DN-Formate, die zuverlässiger sind als die Verwendung eines herkömmlichen Formats.)
- Für den Bindevorgang wird kein Dienstkonto verwendet, sondern ein persönliches Konto des Entwicklers oder Administrators (stellen Sie sich vor, was passiert, wenn der Kontoinhaber das Unternehmen verlässt).
- Senden von Passwörtern im Klartext an Port 389.
- In einigen Anwendungen ist das Kontrollkästchen "Zertifikat validieren" nicht erforderlich, wenn eine Verbindung zu AD über TLS (Port 636) hergestellt wird. Warum ist das allgemein akzeptabel? Wie kann ich das Passwort an einen Drittanbieter weitergeben, ohne von seiner Echtheit überzeugt zu sein?
Es ist einfach, den LDAP-Client zum Laufen zu bringen. Aber nur die Tatsache, dass es funktioniert, bedeutet nicht, dass die Konfiguration korrekt ist.
6. LDAP-Authentifizierung und moderne Authentifizierungsdienste schließen sich gegenseitig aus
Eine Anwendung, die LDAP zur Authentifizierung verwendet, muss sich immer auf Benutzernamen und Kennwörter verlassen. Der Versuch, moderne Technologien wie die Multi-Faktor-Authentifizierung und die einmalige Anmeldung zu implementieren, ist fast unmöglich (es sei denn, Sie implementieren Ihre eigenen Technologien, was an sich schon eine schlechte Idee ist). Die FIDO Alliance setzt sich dafür ein, Passwörter zu einem Relikt der Vergangenheit zu machen, und jede Anwendung, die LDAP-Authentifizierung verwendet, wird ein Hindernis für eine kennwortfreie Richtlinie sein.
Welche Möglichkeiten gibt es?
Webanwendungen können heutzutage wirklich ohne LDAP-Authentifizierung auskommen. Es gibt viele hervorragende Webauthentifizierungsprotokolle wie SAML, WS-Federation und OpenID Connect, für die keine Benutzeranmeldeinformationen erforderlich sind, um mit Anwendungen von Drittanbietern zu arbeiten. Zahlreiche Produkte bieten diese Dienste an, darunter der Active Directory-Verbunddienst (in Windows Server integriert) oder Dienste von Drittanbietern wie Microsoft Azure AD, Okta, Ping und andere. Wenn Ihre Organisation nicht über einen Verbund-IDP verfügt, müssen Sie diesen zunächst implementieren.
Das Wichtigste, auf das Sie bei der Auswahl einer neuen Software achten sollten, ist die Unterstützung moderner Authentifizierungsprotokolle. Auch wenn das Unternehmen die Anwendung hier und jetzt benötigt, sollten Sie sich nicht beeilen, eine Lösung auszuwählen, insbesondere, wenn diese Auswahl nur auf Produkte mit LDAP-Authentifizierung beschränkt ist. Es lohnt sich, dem ausgewählten Anbieter die Notwendigkeit zu vermitteln, das Produkt mit moderneren Authentifizierungsprotokollen zu verfeinern. Vielleicht hört er zu und überarbeitet seinen Entwicklungsplan.
Die Anzahl der Desktop-Anwendungen mit einem "Thick Client", der moderne Authentifizierungsprotokolle unterstützt, nimmt zu, und dies ist in der Tat ein erfreulicher Trend. Diese Anwendungen waren normalerweise eine Hochburg der LDAP-Authentifizierung. Dank einer wachsenden Anzahl von SDKs, wie der Microsoft Authentication Library (MSAL), können Entwickler ihren mobilen und Desktop-Anwendungen auf einfache Weise Unterstützung für moderne Authentifizierungsdienste hinzufügen.
Letztendlich ist es erwähnenswert, dass in der heutigen Realität nicht alle Anwendungen moderne Authentifizierungsprotokolle unterstützen und dies möglicherweise niemals sein wird. Die Implementierung eines vollständigen Verbots der LDAP-Authentifizierung ist wahrscheinlich in keiner Organisation möglich. Die LDAP-Authentifizierung sollte jedoch in keiner Weise innerhalb des Unternehmens gefördert werden. Die Verwendung von LDAP sollte nur in Betracht gezogen werden, wenn keine anderen Optionen verfügbar sind.