HTTP-Authentifizierung

RFC 7235 definiert das HTTP-Authentifizierungsframework, das von einem Server verwendet werden kann, um eine Clientanforderung zu challengen, und von einem Client, um Authentifizierungsinformationen bereitzustellen.

Der Ablauf von Challenge und Response funktioniert so:

1. Der Server antwortet auf eine Clientanfrage mit einem 401 (Unauthorized) Statuscode und gibt Informationen zur Autorisierung an, indem er einen WWW-Authenticate Antwortheader enthält, der mindestens eine Challenge enthält.
2. Ein Client, der sich beim Server authentifizieren möchte, kann dies tun, indem er einen Authorization Anfrageheader mit den Anmeldedaten einfügt.
3. Normalerweise zeigt ein Client dem Benutzer eine Passwortaufforderung an und sendet dann die Anfrage mit dem richtigen Authorization-Header.

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

Der gleiche Mechanismus von Challenge und Response kann für die Proxy-Authentifizierung verwendet werden. Da Ressourcen- und Proxy-Authentifizierung koexistieren können, wird ein anderer Satz von Headern und Statuscodes benötigt. Im Fall von Proxies ist der herausfordernde Statuscode 407 (Proxy Authentication Required), der Proxy-Authenticate Antwortheader enthält mindestens eine für den Proxy anwendbare Challenge, und der Proxy-Authorization Anfrageheader wird verwendet, um die Anmeldedaten an den Proxyserver 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 Headerfeld ersetzen.

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

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

Ein potenzielles Sicherheitsloch (das in Browsern inzwischen behoben wurde) war die Authentifizierung von Cross-Site-Bildern. 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), was verhindert, dass Benutzeranmeldedaten gestohlen werden, wenn Angreifer in der Lage wären, ein beliebiges Bild in eine Drittanbieter-Seite einzubetten.

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

Firefox verwendete einmal ISO-8859-1, wechselte jedoch zu utf-8 für die Parität mit anderen Browsern und um potenzielle Probleme zu vermeiden, wie in Firefox bug 1419658 beschrieben.

Die WWW-Authenticate und Proxy-Authenticate Antwortheader definieren die Authentifizierungsmethode, die verwendet werden sollte, um Zugang zu einer Ressource zu erhalten. Sie müssen angeben, welches Authentifizierungsschema verwendet wird, damit der Client, der autorisieren möchte, weiß, wie die Anmeldedaten bereitzustellen sind.

Die Syntax für diese Header ist die folgende:

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

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

Die Authorization und Proxy-Authorization Anfrageheader enthalten die Anmeldedaten, um einen Benutzeragenten bei einem (Proxy-)Server zu authentifizieren. Hierbei wird <type> erneut benötigt, gefolgt von den Anmeldedaten, die kodiert oder verschlüsselt sein können, je nachdem, welches Authentifizierungsschema verwendet wird.

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

Das allgemeine HTTP-Authentifizierungsframework ist die Grundlage für eine Reihe von Authentifizierungsschemata.

Die IANA pflegt eine Liste der Authentifizierungsschemata, aber es gibt andere Schemata, die von Host-Services, wie zum Beispiel Amazon AWS, angeboten werden.

Einige gängige Authentifizierungsschemata umfassen:

Basic

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

Bearer

Siehe RFC 6750, Inhabertokens zum Zugriff auf 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, digital-signaturbasiert.

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 zur AWS3-Serverauthentifizierung verwendet.

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

Das "Basic"-Authentifizierungsschema bietet sehr geringe Sicherheit, wird jedoch weit unterstützt und ist einfach einzurichten. Es wird unten ausführlicher eingeführt.

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

Da die Benutzer-ID und das Passwort im Netzwerk als Klartext übermittelt werden (sie sind base64-codiert, aber base64 ist eine reversible Codierung), ist das Basic-Authentifizierungsschema nicht sicher. HTTPS/TLS sollte mit Basic-Authentifizierung verwendet werden, um das Abfangen von Anmeldedaten zu verhindern.

Darüber hinaus sind Seiten, die HTTP Basic Auth verwenden, besonders anfällig für Cross-Site Request Forgery (CSRF)-Angriffe, da die Benutzeranmeldedaten bei allen Anfragen ungeachtet des Ursprungs gesendet werden (dies unterscheidet sich von cookie-basierten Anmeldemechanismen, da Cookies in Cross-Site-Anfragen häufig blockiert werden). Seiten sollten immer POST-Anfragen verwenden, wenn Daten geändert werden, und CSRF-Token einfügen.

Ohne diese Sicherheitsverbesserungen sollte Basic-Authentifizierung nicht verwendet werden, um sensible oder wertvolle Informationen zu schützen.

Um ein Verzeichnis auf einem Apache-Server passwortzuschü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 sehen, da sie gehasht sind (in diesem Fall durch MD5-basiertes 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 Ort angeben, den Sie schützen möchten, sowie die auth_basic-Direktive, die den Namen des passwortgeschützten Bereichs bereitstellt. Die auth_basic_user_file-Direktive verweist 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;
}

Historisch gesehen erlaubten einige Seiten die Anmeldung über eine kodierte 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 von der Anfrage entfernt, bevor sie gesendet wird.

• WWW-Authenticate
• Authorization
• Proxy-Authorization
• Proxy-Authenticate
• 401, 403, 407
• HTTP-Sicherheits-Leitfäden