Prof. Dr. Detlef Stern

HTTP Basic Auth als Infrastruktur zur Authentifizierung

Kaum eine web-basierte Software kommt ohne Authentifizierung aus, d.h. ein Benutzer muss sich identifizieren, damit er ggf. Berechtigungen erhält (also autorisiert wird). In den meisten Fällen erfolgt die Authentifizierung über eine Anmeldemaske, bei der ein Benutzername und ein Passwort anzugeben sind. Stimmen beide mit hinterlegten Daten überein, so scheint die Identität des Benutzer geklärt und er kann auf Basis der ihm zugeordneten Berechtigungen mit der Software arbeiten. So weit, so einfach.

Problemstellung

Doch weit gefehlt. Immer wieder fallen Betreiber von Webseiten auf, die bei der Hinterlegung der Authentifizierungsdaten unangemessene Verfahren verwenden. Die Website Have I Been Pwned sammelt solche Fälle. Die aktuell knapp 400 Websites, bei denen für mehr als 8 Milliarden Benutzer die Authentifizierungsdaten bekannt sind, stellen sicher nicht mehr als die berühmte Spitze des Eisbergs dar. Es ist also nötig, die Daten zur Authentifizierung einigermaßen geschützt zu speichern.

Auf den ersten Blick etwas konträr steht der Wunsch, im Kontext eines Unternehmens (oder einer Hochschule) nur einen Benutzernamen und ein Passwort für viele Dienste zu verwenden. Da viele Menschen sich nur wenig merken können (oder wollen) und viele keinen Passwortmanager verwenden, tendieren diese daher, eher einfache Passworte zu verwenden, wenn auch nicht immer „12345“. Ein zentrales Passwort erlaubt es dem IT-Support schneller auf Probleme der Benutzer bzgl. der Zugangsdaten einzugehen.

Diese Authentifizierungs- oder Zugangsdaten werden üblicherweise durch ein zentrales System verwaltet, dass besser redundant ausgelegt sein sollte. Denn wenn dieses System nicht verfügbar ist, kann kein Benutzer alle organisationsspezifischen Dienste nutzen. In meinem Hochschulekontext wären das: Email, Intranet der Hochschule, Lehrmanagementsystem, Noteneingabe, Bearbeitung des Modulhandbuchs, Finanzdaten, … Für Studenten gilt ähnliches.

Auch bei einer web-basierten Software, deren Benutzer nicht zu einer einzigen Organisation gehören, kann es sich lohnen, die Authentifizierung auszulagern. Sicher haben manche schon ein „Login via SM-Dienst“ genutzt.

Realisierung in der HS-Praxis

Ich selbst habe die die eine oder andere web-basierte Software für den Einsatz in der Hochschule implementiert. Studenten implementieren solche Software im Rahmen von Projektstudien ebenfalls immer mal wieder. Beispiele sind die Software zum Agilen Studieren, zur Gruppeneinteilung oder zur Unterstützung des Geschäftsprozesses „Anmeldung zur Prüfungseinsicht“.

In meiner Hochschule werden die Authentifizierungsdaten in einem zentralen LDAP-Dienst vorgehalten. Der Zugriff auf diesen Dienst ist aus guten Gründen eingeschränkt. Darüber hinaus ist etwas knifflig, diesen Dienst programmiertechnisch zu nutzen (wenn man Zugriff besitzt). Üblicherweise erhalten Studenten keinen Zugriff. Wie sollen die also ihre web-basierte Software testen?

An anderen Hochschulen werden womöglich andere Dienste verwendet, so dass zur Authentifizierung eine Abstraktionsschicht verwendet werden sollte. Aber welche?

Lösungsansatz

Viele Webserver bieten von Haus aus vielfältige Möglichkeiten der Authentifierung. Diese müssen ggf. über Plugins aktiviert werden. So bietet zum Beispiel der Apache Webserver die Möglichkeit die Authentifizierungsdaten in einer Datei, in unterschiedlichen Datenbanken oder in einem LDAP-Dienst vorzuhalten. Über selbst geschriebene Plugins können weitere Dienste genutzt werden.

Warum sollen meine Studenten (und auch ich) etwas programmieren, für das es schon eine Lösung gibt? Offen ist nur, wie man dies in der eigenen Software nutzt.

Dazu existiert schon (fast) seit Anbeginn des Webs ein Standard, wie sich Benutzer gegenüber einem Webserver authentifizieren können: HTTP Basic Authentication, aktuell beschrieben im RFC7617. Diese Art der Authentifizierung wird aktuell selten genutzt, da alle Webbrowser diesen etwas unschön umsetzen. Es öffnet sich keine hübsche, an der web-basierten Software optisch angepasste Anmeldemaske, sondern ein Popup-Formular, meist in grau, das es dem Benutzer häufig nicht einmal erlaubt, einen anderen Browser-Tab zu öffnen.

Der Vorteil dieser Authentifizierung ist aber, dass Benutzername und Passwort auch in einer Webadresse (URL, eigentlich URI) angegeben werden können. Der Standard RFC3986 erlaubt dies noch. Die üblichen Bibliotheken zur programmtechnischen Abfrage von Webservern unterstützen dies.

Um also in einer Software (ob web-basiert oder nicht, das ist unerheblich) zu prüfen, ob die Kombination aus Benutzername und Passwort gültig ist, braucht man „nur“ einen Webserver entsprechend zu konfigurieren, indem der Zugriff auf eine Web-Ressource (identifiziert durch eine URI) durch den Webserver authentifiziert werden muss. Wenn der Webserver den Zugriff erlaubt, ist gehören Benutzername und Passwort zusammen, der Benutzer ist auch für meine Software authentifiziert. Wie der Webserver die Ressource tatsächlich authentifiziert, ist der Software egal.

Angenommen, der Web-Server zur Authentifizierung ist so konfiguriert worden, dass die Ressource unter der URI https://t73f.de/auth/ erreichbar ist, dann braucht meine Software (oder die meiner Studenten) als URI nur https://stern:12345@t73f.de/auth/ verwenden, um zu prüfen, ob das Passwort für den Benutzer stern tatsächlich 12345 lautet.

Bewertung

Für den Produktivbetrieb einiger eigener Web-Anwendungen nutzen wir dieses Prinzip tatsächlich. Die Software für das Agile Studieren und die zur Gruppeneinteilung greifen zur Authentifizierung auf einen internen (Apache) Webserver zu, der die Anfrage an den internen LDAP-Dienst weiterleitet. Nur dieser interne Webserver musste für den Zugriff auf den LDAP-Dienst zugelassen werden, auch in Zukunft muss unser Rechenzentrum, als Betreiber des LDAP-Dienstes, keine weitere Software zulassen. Weiterer Vorteil: alle Hochschulmitglieder können diese Web-Anwendungen ohne weitere Registrierung o.ä. nutzen.

Während der Programmierung ist der indirekte Zugriff auf den internen LDAP-Dienst nicht nützlich. Wie sollte ich sonst zum Beispiel bei der Gruppeneinteilung den Teil für die Studenten testen? Natürlich könnte ich mir einen eigenen Apache Webserver aufsetzen, mit einer anderen Konfiguration für die Authentifizierung und eine andere Basis-URI verwenden. Viel einfacher ist ein kleiner, selbst programmierter Mini-Webserver, der jede Kombination aus Benutzername und Passwort erfolgreich authentifiziert, es sei denn, der Benutzername beginnt mit einem x. So kann ich als Softwareentwickler auf beliebig viele Benutzernamen zugreifen und kann alles notwendige testen.

Für Web-Anwendungen, die mit Hilfe von Django programmiert werden, habe ich einen kleinen Adapter veröffentlicht, der das hier beschriebene Verfahren umsetzt. Der im vorigen Abschnitt angesprochene Mini-Webserver für die Programmierphase wird folgen.

Ein weiterer Vorteil sind mögliche weitergehende Dienste, die man mit Hilfe dieser Infrastruktur einfach umsetzen kann. Möchte man zum Beispiel verhindern, dass ein Angreifer automatisiert viele Kombinationen aus Benutzername und Passwort prüft, so könnte man seinen Webserver dahingehend konfigurieren, dass dies unterbunden wird. Oder man programmiert sich einen eigenen kleinen Mini-Webserver, der Anfragen weiterleitet, sich Fehlversuche merkt und nach Überschreiten einer Schwelle (Anzahl von Fehlersuchen pro Zeiteinheit und/oder Zeit zwischen zwei Versuchen) zeitlich befristet ein „Nicht authentifiziert“ zurückgibt oder gar nicht mehr auf Anfragen für einen Benutzernamen antwortet.

Damit müssen diese sicherheitskritischen Aspekte nicht bei jeder Web-Anwendung immer wieder neu programmiert werden, sondern werden einmal zentral bereitgestellt.

Wie bei jedem sicherheitskritischen Aspekt gibt es einen Zwang zum Selbstzweifel: habe ich etwas übersehen?