HTTP-Authentifizierung

RFC 7235 definiert den HTTP-Authentifizierungsrahmen, der von einem Server genutzt werden kann, um eine Challenge an eine Client-Anfrage zu senden, und von einem Client, um Authentifizierungsinformationen bereitzustellen.

Der Ablauf von Challenge und Antwort funktioniert so:

1. Der Server antwortet einem Client mit einem 401 (Unauthorized)-Antwortstatus und liefert Informationen, 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 beifügt.
3. In der Regel wird ein Client einem Benutzer ein Passwortfeld anzeigen und dann die Anfrage mit dem korrekten Authorization-Header senden.

Der allgemeine Nachrichtenfluss, wie oben beschrieben, ist der gleiche für die meisten (wenn nicht alle) Authentifizierungsschemata. Die tatsächlichen Informationen in den Headern und die Art, wie sie kodiert sind, ändern sich!

Der gleiche Mechanismus von Challenge und Antwort kann für Proxy-Authentifizierung verwendet werden. Da sowohl Ressourcen-Authentifizierung als auch Proxy-Authentifizierung koexistieren können, ist eine andere Menge an Headern und Statuscodes erforderlich. Im Fall von Proxys ist der herausfordernde Statuscode 407 (Proxy Authentication Required), der Proxy-Authenticate-Antwortheader enthält mindestens eine Challenge, die auf den Proxy anwendbar ist, und der Proxy-Authorization-Anfrageheader wird verwendet, um die Anmeldedaten dem Proxy-Server bereitzustellen.

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.

Wenn ein (Proxy-)Server gültige Anmeldedaten erhält, die nicht ausreichen, um auf eine bestimmte Ressource zuzugreifen, sollte der Server mit dem 403-Statuscode Forbidden antworten. Im Gegensatz zu 401 Unauthorized oder 407 Proxy Authentication Required ist eine Authentifizierung für diesen Benutzer unmöglich und Browser schlagen keinen neuen Versuch vor.

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

Ein potenzielles Sicherheitsloch (das mittlerweile in Browsern behoben wurde) war die Authentifizierung von Cross-Site-Bildern. Ab Firefox 59 können Bildressourcen, die von anderen Ursprüngen als dem aktuellen Dokument geladen werden, keine HTTP-Authentifizierungsdialoge mehr auslösen (Firefox Bug 1423146), was verhindert, dass Benutzerdaten gestohlen werden, wenn Angreifer in der Lage wären, ein beliebiges Bild in eine Drittanbieterseite einzubetten.

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

Firefox verwendete früher ISO-8859-1, wechselte jedoch zu utf-8 zur Angleichung an andere Browser und zur Vermeidung potenzieller Probleme, wie im Firefox Bug 1419658 beschrieben.

Die WWW-Authenticate- und Proxy-Authenticate-Antwortheader definieren die Authentifizierungsmethode, die zur Erlangung des Zugangs zu einer Ressource verwendet werden sollte. Sie müssen angeben, welches Authentifizierungsschema genutzt wird, damit der Client, der sich autorisieren möchte, weiß, wie er die Anmeldedaten bereitstellten kann.

Die Syntax für diese Header ist folgende:

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

Hierbei ist <type> das Authentifizierungsschema ("Basic" ist das gebräuchlichste Schema und wird unten vorgestellt). Der Realm wird verwendet, um den geschützten Bereich zu beschreiben oder um den Schutzbereich anzuzeigen. Dies könnte eine Nachricht wie "Zugang zur Staging-Seite" oder ähnliches sein, damit der Benutzer weiß, zu welchem Bereich er Zugang zu erhalten versucht.

Die Authorization- und Proxy-Authorization-Anfrageheader enthalten die Anmeldedaten, um einen Benutzer-Agent beim (Proxy-)Server zu authentifizieren. Hierbei wird wieder der <type> benötigt, gefolgt von den Anmeldedaten, die kodiert oder verschlüsselt sein können, abhängig vom verwendeten Authentifizierungsschema.

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

Der allgemeine HTTP-Authentifizierungsrahmen ist die Grundlage für eine Reihe von Authentifizierungsschemata.

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

Einige gängige Authentifizierungsschemata sind:

Basic

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

Bearer

Siehe RFC 6750, Bearer-Tokens zum 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 Authentifizierung

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.

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

Das "Basic"-Authentifizierungsschema bietet eine sehr geringe Sicherheit, ist jedoch weit verbreitet und einfach einzurichten. Es wird im Folgenden näher erläutert.

Das "Basic" HTTP-Authentifizierungsschema ist in RFC 7617 definiert und überträgt Anmeldedaten als Benutzer-ID/Passwort paarweise, kodiert mit base64.

Da die Benutzer-ID und das Passwort über das Netzwerk im Klartext übermittelt werden (sie sind base64-kodiert, aber base64 ist eine umkehrbare Kodierung), ist das Basic-Authentifizierungsschema nicht sicher. HTTPS/TLS sollte mit Basic-Authentifizierung verwendet werden. Ohne diese zusätzlichen Sicherheitsvorkehrungen sollte die Basic-Authentifizierung nicht verwendet werden, um sensible oder wertvolle Informationen zu schützen.

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 typischerweise so aus:

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

Die .htaccess-Datei verweist auf eine .htpasswd-Datei, in der jede Zeile aus einem Benutzernamen und einem durch einen Doppelpunkt (:) getrennten Passwort besteht. Sie können die tatsächlichen Passwörter nicht einsehen, da sie gehasht sind (unter Verwendung von MD5-basiertem Hashing, in diesem Fall). Beachten Sie, dass Sie die .htpasswd-Datei anders benennen können, wenn Sie möchten, aber denken Sie daran, 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-Directive, die den Namen für den passwortgeschützten Bereich angibt. Die auth_basic_user_file-Directive verweist dann auf eine .htpasswd-Datei, die die verschlüsselten Benutzerdaten enthält, genau wie im obigen Apache-Beispiel.

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

Viele Clients lassen Sie auch das Anmeldefeld umgehen, indem Sie eine kodierte URL verwenden, die den Benutzernamen und das Passwort auf diese Weise enthält:

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

Die Verwendung dieser URLs ist veraltet. In Chrome wird der username:password@-Teil aus URLs aus Subressourcen-URLs entfernt aus Sicherheitsgründen. In Firefox wird überprüft, ob die Seite tatsächlich eine Authentifizierung erfordert, und falls nicht, warnt Firefox den Benutzer mit einer Eingabeaufforderung "Sie sind dabei, sich auf der Seite www.example.com mit dem Benutzernamen username anzumelden, aber die Webseite verlangt keine Authentifizierung. Dies könnte ein Versuch sein, Sie zu täuschen." Sofern die Seite Authentifizierung erfordert, wird Firefox dennoch um eine Bestätigung des Benutzers bitten "Sie sind dabei, sich auf 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 die Eingabeaufforderung angezeigt wird, um festzustellen, ob die Seite Authentifizierung erfordert.

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