HTTP-Authentifizierung

RFC 7235 definiert das HTTP-Authentifizierungsrahmenwerk, welches von einem Server genutzt werden kann, um eine Challenge an eine Client-Anfrage zu senden und vom Client zur Bereitstellung von Authentifizierungsinformationen.

Der Ablauf von Challenge und Antwort funktioniert folgendermaßen:

1. Der Server antwortet dem Client mit einem 401 (Unauthorized) Antwortstatus und gibt Informationen darüber, wie man sich mit einem WWW-Authenticate Antwortheader, der mindestens eine Challenge enthält, autorisieren kann.
2. Ein Client, der sich beim Server authentifizieren möchte, kann dies tun, indem er einen Authorization Anfrageheader mit den Anmeldedaten einschließt.
3. In der Regel wird der Client dem Benutzer eine Passwortabfrage präsentieren und dann die Anfrage mit dem korrekten Authorization-Header ausführen.

Der allgemeine Nachrichtenaustausch oben ist bei den meisten (wenn nicht allen) Authentifizierungsschemata gleich. Die tatsächlichen Informationen in den Headers und die Art und Weise, wie sie kodiert sind, variieren jedoch!

Der gleiche Challenge- und Antwortmechanismus kann auch für die Proxy-Authentifizierung verwendet werden. Da sowohl Ressourcen- als auch Proxy-Authentifizierung koexistieren können, wird ein anderer Satz von Headern und Statuscodes benötigt. Im Falle von Proxys ist der herausfordernde Statuscode 407 (Proxy Authentication Required), der Proxy-Authenticate Antwortheader enthält mindestens eine auf den Proxy anwendbare Herausforderung, und der Proxy-Authorization Anfrageheader wird verwendet, um die Anmeldedaten an den Proxy-Server zu übermitteln.

Wenn ein (Proxy-)Server ungültige Anmeldedaten erhält, sollte er mit einem 401 Unauthorized oder einem 407 Proxy Authentication Required antworten, und der Benutzer kann eine neue Anfrage senden oder das Authorization Header-Feld ersetzen.

Erhält ein (Proxy-)Server gültige Anmeldeinformationen, die unangemessen sind, um auf eine bestimmte Ressource zuzugreifen, sollte der Server mit dem Statuscode 403 Forbidden antworten. Im Gegensatz zu 401 Unauthorized oder 407 Proxy Authentication Required ist die Authentifizierung für diesen Benutzer unmöglich, und Browser werden keinen neuen Versuch vorschlagen.

In allen Fällen kann der Server vorzugsweise einen 404 Not Found Statuscode zurückgeben, um die Existenz der Seite vor einem Benutzer ohne ausreichende Berechtigungen oder nicht korrekt authentifiziert zu verbergen.

Ein potenzielles Sicherheitsloch (das inzwischen in Browsern behoben wurde) war die Authentifizierung von CORS-Images. Ab Firefox 59 können Bildressourcen, die von anderen Ursprüngen als das aktuelle Dokument geladen werden, keine HTTP-Authentifizierungsdialoge mehr auslösen (Firefox-Bug 1423146), um zu verhindern, dass Benutzerdaten gestohlen werden, falls Angreifer ein beliebiges Bild in eine Drittanbieter-Seite einbetten könnten.

Browser verwenden die utf-8-Codierung für Benutzernamen und Passwörter.

Firefox benutzte früher ISO-8859-1, änderte aber auf utf-8 zur Angleichung an andere Browser und um potenzielle Probleme zu vermeiden, wie in Firefox-Bug 1419658 beschrieben.

Die WWW-Authenticate und Proxy-Authenticate Antwortheaders definieren die Authentifizierungsmethode, die verwendet werden sollte, um Zugang zu einer Ressource zu erhalten. Sie müssen das verwendete Authentifizierungsschema spezifizieren, sodass der Client, der sich autorisieren möchte, weiß, wie die Anmeldeinformationen bereitgestellt werden müssen.

Die Syntax dieser Header ist die folgende:

WWW-Authenticate: <type> realm=<realm>
Proxy-Authenticate: <type> realm=<realm>

Hierbei ist <type> das Authentifizierungsschema ("Basic" ist das häufigste Schema und unten eingeführt). Der realm wird verwendet, um den geschützten Bereich zu beschreiben oder den Schutzbereich anzuzeigen. Dies könnte eine Nachricht wie "Zugang zur Staging-Seite" oder ähnlich sein, damit der Benutzer weiß, auf welchen Bereich er zugreifen möchte.

Die Authorization und Proxy-Authorization Anfrageheaders enthalten die Anmeldedaten, um einen Benutzer-Agenten bei einem (Proxy-)Server zu authentifizieren. Hierbei ist wieder <type> erforderlich, gefolgt von den Anmeldeinformationen, die je nach verwendetem Authentifizierungsschema kodiert oder verschlüsselt sein können.

Authorization: <type> <credentials>
Proxy-Authorization: <type> <credentials>

Das allgemeine HTTP-Authentifizierungsrahmenwerk ist die Grundlage für eine Vielzahl von Authentifizierungsschemata.

IANA pflegt eine Liste der Authentifizierungsschemata, aber es gibt andere Schemata, die von Hostdiensten angeboten werden, z.B. Amazon AWS.

Einige gängige Authentifizierungsschemata umfassen:

Basic

Siehe RFC 7617, base64-kodierte Anmeldedaten. Weitere Informationen unten.

Bearer

Siehe RFC 6750, Token für den Zugriff auf OAuth 2.0-geschützte Ressourcen

Digest

Siehe RFC 7616. Firefox 93 und später unterstützen den SHA-256-Algorithmus. Frühere Versionen unterstützen nur MD5-Hashing (nicht empfohlen).

HOBA

Siehe RFC 7486, Abschnitt 3, HTTP Origin-Bound Authentication, signaturbasierte

Mutual

Siehe RFC 8120

Negotiate / NTLM

Siehe RFC4599

VAPID

Siehe RFC 8292

SCRAM

Siehe RFC 7804

AWS4-HMAC-SHA256

Siehe AWS-Dokumentation. Dieses Schema wird für die AWS3-Server-Authentifizierung verwendet.

Die Schemata können sich in der Sicherheitsstärke und ihrer Verfügbarkeit in Client- oder Server-Software unterscheiden.

Das "Basic"-Authentifizierungsschema bietet sehr geringe Sicherheit, ist jedoch weit verbreitet und einfach einzurichten. Es wird weiter unten ausführlicher erläutert.

Das HTTP-"Basic"-Authentifizierungsschema ist in RFC 7617 definiert, das Anmeldedaten als Benutzer-ID/Passwort-Paare überträgt, die mithilfe von base64 kodiert werden.

Da die Benutzer-ID und das Passwort im Klartext über das Netzwerk übertragen werden (es ist base64-kodiert, aber base64 ist eine umkehrbare Kodierung), ist das Basic-Authentifizierungsschema nicht sicher. HTTPS/TLS sollte bei der Basic-Authentifizierung verwendet werden. Ohne diese zusätzlichen Sicherheitsverbesserungen sollte die Basic-Authentifizierung nicht zum Schutz sensibler oder wertvoller Informationen verwendet werden.

Um ein Verzeichnis auf einem Apache-Server mit einem Passwort zu schützen, benötigen Sie eine .htaccess- und eine .htpasswd-Datei.

Die .htaccess-Datei sieht in der Regel so aus:

AuthType Basic
AuthName "Access to the staging site"
AuthUserFile /path/to/.htpasswd
Require valid-user

Die .htpasswd-Datei enthält in jeder Zeile einen Benutzernamen und ein Passwort, getrennt durch einen Doppelpunkt (:). Sie können die tatsächlichen Passwörter nicht sehen, da sie gehasht sind (in diesem Fall unter Verwendung von MD5-basiertem Hashing). Beachten Sie, dass Sie Ihre .htpasswd-Datei anders benennen können, wenn Sie möchten, aber bedenken Sie, dass diese Datei für niemanden zugänglich sein sollte. (Apache ist normalerweise so konfiguriert, dass der Zugriff auf .ht*-Dateien verhindert wird).

aladdin:$apr1$ZjTqBB3f$IF9gdYAGlMrs2fuINjHsz.
user2:$apr1$O04r.y2H$/vEkesPhVInBByJUkXitA/

Für Nginx müssen Sie einen Standort angeben, den Sie schützen möchten, und die auth_basic-Direktive, die den Namen des passwortgeschützten Bereichs angibt. Die auth_basic_user_file-Direktive zeigt dann auf eine .htpasswd-Datei, die die verschlüsselten Benutzeranmeldedaten enthält, genau wie im Apache-Beispiel oben.

location /status {
    auth_basic           "Access to the staging site";
    auth_basic_user_file /etc/apache2/.htpasswd;
}

Viele Clients ermöglichen es Ihnen auch, das Anmelde-Prompt zu vermeiden, indem Sie eine kodierte URL verwenden, die den Benutzernamen und das Passwort enthält, wie folgt:

https://username:password@www.example.com/

Die Verwendung dieser URLs ist veraltet. In Chrome wird der username:password@ Teil in URLs aus Subressourcen-URLs entfernt aus Sicherheitsgründen. In Firefox wird überprüft, ob die Seite tatsächlich eine Authentifizierung erfordert, und falls nicht, wird Firefox den Benutzer mit einem Prompt warnen: "Sie sind dabei, sich bei der Seite www.example.com mit dem Benutzernamen username anzumelden, aber die Website erfordert keine Authentifizierung. Dies könnte ein Versuch sein, Sie zu täuschen." Falls die Seite tatsächlich eine Authentifizierung erfordert, wird Firefox dennoch um die Bestätigung des Benutzers bitten: "Sie sind dabei, sich bei der Seite www.example.com mit dem Benutzernamen username anzumelden," bevor die Anmeldedaten an die Seite gesendet werden. Beachten Sie, dass Firefox in beiden Fällen die Anfrage ohne Anmeldedaten sendet, bevor der Prompt angezeigt wird, um festzustellen, ob die Seite eine Authentifizierung erfordert.

• WWW-Authenticate
• Authorization
• Proxy-Authorization
• Proxy-Authenticate
• 401, 403, 407