HTTP-Authentifizierung

HTTP-Authentifizierung ist ein Verfahren, mit dem sich der Nutzer eines Webbrowsers gegenüber dem Webserver bzw. einer Webanwendung als Benutzer authentisieren kann, um danach für weitere Zugriffe autorisiert zu sein.

Es ist Teil des Hypertext Transfer Protocol (HTTP), das die Grundlage des World Wide Web bildet.

Stellt der Webserver fest, dass für eine angeforderte URL Benutzername oder Passwort nötig sind, meldet er das dem Browser mit dem Statuscode 401 Unauthorized und dem Header WWW-Authenticate. Der Browser ermittelt nun die zur Anmeldung notwendigen Daten (indem er den Nutzer fragt oder schon früher eingegebene Werte verwendet) und sendet das Ergebnis dem Server, der daraufhin bei korrekten Zugangsdaten die gewünschte Seite, ansonsten eine entsprechende Fehlermeldung, übermittelt.

Serverseitig ist die Authentifizierung entsprechend zu konfigurieren, beim Apache HTTP Server etwa durch Notation entsprechender durch Authentifizierungsmodule bereitgestellter Direktiven in einer .htaccess-Datei oder einer zentralen Serverkonfigurationsdatei.

Der Nutzer ist nach Ablauf des Protokolls gegenüber dem Webserver authentifiziert, allerdings gilt die Umkehrung nicht: Der Nutzer kann nicht sicher sein, dass der Webserver wirklich der ist, der er vorgibt zu sein. Ein Spoofing-Angriff kann einen legitimen Webserver vortäuschen, um beispielsweise an weitere Nutzerdaten zu gelangen. Üblicherweise wird für die Authentifizierung des Webservers gegenüber dem Nutzer ein Sicherheitsprotokoll wie Hypertext Transfer Protocol Secure (HTTPS) benutzt, welches mit Hilfe von digitalen Zertifikaten die Identität des Webservers bestätigen kann.

Größere Webauftritte verwenden dieses standardisierte Verfahren nur noch selten, da sich die Eingabefelder für Benutzername und Passwort nicht gestalten und nicht so einfach in die eigene Webseite einbinden lassen wie bei einem HTML-Formular. Teils wird die HTTP-Auth-Abfrage auch durch eigene JavaScript-Funktionen ergänzt.

Auf einfachen Homepages ist HTTP-Authentifizierung öfter zu finden, da keine Programmierung notwendig ist. Viele Webspace-Provider bieten dabei eine einfache Möglichkeit zur Konfiguration per Web-Interface.

Es gibt mehrere Möglichkeiten, Benutzer (Clients) zu authentifizieren. Verbreitet sind:

Die Basic Authentication (Basisauthentifizierung) wird seit 2015 durch RFC 7617^[1], welche RFC 2617 von 1999^[2] ablöste, spezifiziert und ist eine häufig verwendete Art der HTTP-Authentifizierung. Der Webserver fordert mit

WWW-Authenticate: Basic realm="RealmName"

eine Authentifizierung an, wobei RealmName eine Beschreibung des geschützten Bereiches darstellt – im nebenstehenden Bild beispielsweise „Logfiles/Server information“. Der Browser sucht daraufhin nach Benutzername/Passwort für diese URL und fragt gegebenenfalls den Benutzer. Anschließend sendet er die Authentifizierung mit dem Authorization-Header in der Form Benutzername:Passwort Base64-codiert an den Server.

Beispiel:

Authorization: Basic d2lraTpwZWRpYQ==

„d2lraTpwZWRpYQ==“ ist die Base64-Codierung von wiki:pedia und steht damit für Benutzername wiki, Passwort pedia.

Ein Nachteil dieses Verfahrens ist, dass Benutzername und Passwort nur aus technischen Gründen codiert, jedoch nicht verschlüsselt werden. Aus sicherheitstechnischer Sicht ist dieses Verfahren daher genauso unsicher als würde das Passwort im Klartext übertragen werden. Bei einer Verschlüsselung mit SSL/TLS bei HTTPS wird bereits vor der Übermittlung des Passwortes eine verschlüsselte Verbindung aufgebaut, so dass auch bei Basic Authentication das Passwort nicht abhörbar ist.

Bei der Digest Access Authentication (spezifiziert in RFC 7616^[3]) sendet der Server zusammen mit dem WWW-Authenticate-Header eine eigens erzeugte zufällige Zeichenfolge (Nonce). Der Browser berechnet den Hashcode (in der Regel MD5) einer Kombination aus Benutzername, Passwort, erhaltener Zeichenfolge, HTTP-Methode und angeforderter URL. Diese sendet er im Authorization-Header zusammen mit dem Benutzernamen und der zufälligen Zeichenfolge zurück an den Server. Dieser berechnet seinerseits die Prüfsumme und vergleicht. Das Verfahren ist damit dem des Message Authentication Code ähnlich.

Vorausgesetzt die benutzte Hashfunktion ist kryptographisch sicher, nützt ein Abhören der Kommunikation einem Angreifer nichts, da sich durch die Nutzung einer Hashfunktion die Zugangsdaten nicht rekonstruieren lassen und diese durch die Nutzung der Nonce für jede Anforderung anders lauten. (Speziell wird die weit verbreitete Hashfunktion MD5 nicht mehr als sicher erachtet.) Die restliche Datenübertragung ist jedoch nicht geschützt. Um dies zu erreichen, kann etwa Hypertext Transfer Protocol Secure (HTTPS) verwendet werden.

In Intranets mit Windows-Servern wird häufig das proprietäre NTLM-Authentifizierungsschema angewandt, das bereits seit Jahren als unsicher gilt.^[4] In Intranets empfiehlt sich deshalb die Absicherung via Kerberos.

• Request Cycle
• Cross-Site-Authentication-Attacke

• RFC: 7617 – Basic HTTP Authentication Scheme. (englisch).
• RFC: 7616 – HTTP Digest Access Authentication. (englisch).
• RFC: 2616 – Hypertext Transfer Protocol – HTTP/1.1. (englisch).

1. ↑ RFC: 7617 – Basic HTTP Authentication Scheme. (englisch).
2. ↑ RFC: 2617 – HTTP Authentication: Basic and Digest Access Authentication. Juni 1999 (englisch).
3. ↑ RFC: 7616 – HTTP Digest Access Authentication. (englisch).
4. ↑ Amit Klein: NTLM HTTP Authentication is insecure by design. In: securityfocus.com. 18. Juli 2005, archiviert vom Original am 2. April 2015; abgerufen am 16. Januar 2026.