imported>Zynex7: /* NTLM HTTP Authentication */

2026-01-16T14:04:16Z

NTLM HTTP Authentication

Neue Seite

'''HTTP-Authentifizierung''' ist ein Verfahren, mit dem sich der Nutzer eines [[Webbrowser]]s gegenüber dem [[Webserver]] bzw. einer [[Webanwendung]] als Benutzer [[Authentifizierung|authentisieren]] kann, um danach für weitere Zugriffe [[Autorisierung|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 [[Uniform Resource Locator|URL]] Benutzername oder Passwort nötig sind, meldet er das dem Browser mit dem [[HTTP-Statuscode|Statuscode]] ''401 Unauthorized'' und dem Header ''WWW-Authenticate''. Der Browser ermittelt nun die zur [[Login (Informationstechnik)|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 [[Digitales Zertifikat|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 [[Hypertext Markup Language|HTML]]-[[Webformular|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 <nowiki>RFC 7617</nowiki><ref>{{RFC-Internet |RFC=7617 |Titel=Basic HTTP Authentication Scheme |Datum=}}</ref>, welche <nowiki>RFC 2617</nowiki> von 1999<ref>{{RFC-Internet |RFC=2617 |Titel=HTTP Authentication: Basic and Digest Access Authentication |Datum=1999-06}}</ref> ablöste, spezifiziert und ist eine häufig verwendete Art der HTTP-Authentifizierung. Der Webserver fordert mit

[[Datei:Http auth iw 10.png|mini|Eingabe von Benutzername und Passwort]]

<code>WWW-Authenticate: Basic realm="RealmName"</code>

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 <code>Benutzername:Passwort</code> [[Base64]]-codiert an den Server.

'''Beispiel:'''

<code>Authorization: Basic d2lraTpwZWRpYQ==</code>

„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 (Kryptographie)|Klartext]] übertragen werden. Bei einer Verschlüsselung mit SSL/TLS bei [[Hypertext Transfer Protocol Secure|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 <nowiki>RFC 7616</nowiki><ref>{{RFC-Internet |RFC=7616 |Titel=HTTP Digest Access Authentication |Datum=}}</ref>) sendet der Server zusammen mit dem WWW-Authenticate-Header eine eigens erzeugte zufällige Zeichenfolge ([[Nonce]]). Der Browser berechnet den [[Hashfunktion|Hashcode]] (in der Regel [[Message-Digest Algorithm 5|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 [[Message-Digest Algorithm 5|MD5]] nicht mehr als [[Message-Digest Algorithm 5#Sicherheit|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 [[Intranet]]s mit [[Microsoft Windows|Windows]]-Servern wird häufig das proprietäre [[NTLM]]-Authentifizierungsschema angewandt, das bereits seit Jahren als unsicher gilt.<ref>{{Internetquelle |autor=Amit Klein |url=https://www.securityfocus.com/archive/1/405541 |titel=NTLM HTTP Authentication is insecure by design |werk=securityfocus.com |datum=2005-07-18 |archiv-url=https://web.archive.org/web/20150402102624/https://www.securityfocus.com/archive/1/405541 |archiv-datum=2015-04-02 |abruf=2026-01-16}}</ref> In Intranets empfiehlt sich deshalb die Absicherung via [[Kerberos (Protokoll)|Kerberos]].

== Siehe auch ==
* [[Request Cycle]]
* [[Cross-Site-Authentication-Attacke]]

== Weblinks ==
* {{RFC-Internet |RFC=7617 |Titel=Basic HTTP Authentication Scheme |Datum=}}
* {{RFC-Internet |RFC=7616 |Titel=HTTP Digest Access Authentication |Datum=}}
* {{RFC-Internet |RFC=2616 |Titel=Hypertext Transfer Protocol – HTTP/1.1 |Datum=}}

== Einzelnachweise ==
<references />

{{SORTIERUNG:HTTP Authentifizierung}}
[[Kategorie:HTTP]]
[[Kategorie:Internet-Anwendungsprotokoll]]

HTTP-Authentifizierung - Versionsgeschichte

imported>Zynex7: /* NTLM HTTP Authentication */