HTTP-Authentifizierung

RFC 7235 definiert das HTTP-Authentifizierungs-Framework, das von einem Server genutzt werden kann, um eine Herausforderung an eine Client-Anfrage zu senden, und von einem Client, um Authentifizierungsinformationen bereitzustellen.

Der Ablauf von Herausforderung und Antwort funktioniert so:

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

Der allgemeine Nachrichtenaustausch oben ist für die meisten (wenn nicht alle) Authentifizierungsschemata gleich. Die tatsächlichen Informationen in den Headern und die Art der Kodierung ändern sich jedoch!

Der gleiche Mechanismus von Herausforderung und Antwort kann für die Proxy-Authentifizierung verwendet werden. Da sowohl die Ressourcen-Authentifizierung als auch die 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 Antwort-Header enthält mindestens eine für den Proxy geltende Herausforderung, und der Proxy-Authorization Anforderungs-Header wird verwendet, um dem Proxy-Server die Anmeldedaten bereitzustellen.

Wenn ein (Proxy-)Server ungültige Anmeldedaten erhält, sollte er mit einem 401 Unauthorized oder mit 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 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 in diesem Fall für diesen Benutzer keine Authentifizierung möglich, und Browser werden keinen neuen Versuch vorschlagen.

In jedem Fall kann der Server es vorziehen, einen 404 Not Found Statuscode zurückzugeben, um die Existenz der Seite für einen Benutzer ohne angemessene Rechte oder nicht korrekt authentifiziert zu verbergen.

Ein potenzielles Sicherheitsloch, das in Browsern mittlerweile 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), wodurch verhindert wird, dass Benutzerdaten gestohlen werden, falls Angreifer in der Lage sind, ein beliebiges Bild in eine Drittanbieter-Seite einzubetten.

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

Firefox verwendete früher ISO-8859-1, änderte jedoch auf utf-8 zur Angleichung an andere Browser und zur Vermeidung potenzieller Probleme, wie in Firefox bug 1419658 beschrieben.

Die WWW-Authenticate und Proxy-Authenticate Antwort-Header definieren die Authentifizierungsmethode, die verwendet werden sollte, um Zugriff auf eine Ressource zu erhalten. Sie müssen angeben, welches Authentifizierungsschema verwendet wird, damit der Client, der sich autorisieren möchte, weiß, wie er die Anmeldedaten bereitstellen muss.

Die Syntax für diese Header ist folgende:

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

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

Die Authorization und Proxy-Authorization Anforderungs-Header enthalten die Anmeldedaten, um einen Benutzeragenten bei einem (Proxy-)Server zu authentifizieren. Auch hier ist <type> erneut benötigt, gefolgt von den Anmeldedaten, die je nach verwendetem Authentifizierungsschema kodiert oder verschlüsselt sein können.

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

Das allgemeine HTTP-Authentifizierungs-Framework bildet die Grundlage für eine Reihe von Authentifizierungsschemata.

IANA unterhält eine Liste von Authentifizierungsschemata, aber es gibt auch andere Schemata, die von Hostdiensten angeboten werden, wie etwa 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 durch OAuth 2.0 geschützte Ressourcen

Digest

Siehe RFC 7616. Firefox 93 und höher 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, basierend auf digitalen Signaturen

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-Serverauthentifizierung 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 im Folgenden ausführlicher vorgestellt.

Das "Basic" HTTP-Authentifizierungsschema ist in RFC 7617 definiert, das Anmeldedaten als Benutzer-ID/Passwort-Paare übermittelt, kodiert mit base64.

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

Um ein Verzeichnis auf einem Apache-Server per 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 Passwort besteht, die durch einen Doppelpunkt (:) getrennt sind. Sie können die tatsächlichen Passwörter nicht sehen, da sie gehasht sind (unter Verwendung von MD5-basiertem Hashing in diesem Fall). 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, ähnlich wie im Apache-Beispiel oben.

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

Historisch gesehen erlaubten einige Seiten die Anmeldung mit einer kodierten URL, die den Benutzernamen und das Passwort enthielt, wie gezeigt:

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

Diese Syntax ist in modernen Browsern nicht mehr erlaubt; der Benutzername und das Passwort werden aus der Anfrage entfernt, bevor sie gesendet wird.

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