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.

Funktion

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.

Verwendung

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.

Verfahren

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

Basic Authentication

Die Basic Authentication (Basisauthentifizierung) wird seit 2015 durch RFC 7617, welche RFC 2617 von 1999 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.

Digest Access Authentication

Bei der Digest Access Authentication (spezifiziert in RFC 7616) 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.

NTLM HTTP Authentication

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

Siehe auch

  • RFC 7617 – Basic HTTP Authentication Scheme. (englisch).
  • RFC 7616 – HTTP Digest Access Authentication. (englisch).
  • RFC 2616 – Hypertext Transfer Protocol – HTTP/1.1. (englisch).
  • Sammlung an nützlichen .htaccess Beispielen. codeblick.de
  • Einrichtung einer verschlüsselten HTTP-Authentifizierung mit htdigest. redirect301.de

Einzelnachweise

  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. ↑ securityfocus.com
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.