4. Sicherheitsüberlegungen (Security Considerations)
4.1 Authentifizierung von Clients mit Basis-Authentifizierung (Authentication of Clients using Basic Authentication)
Das Basis-Authentifizierungsschema (Basic Authentication Scheme) ist keine sichere Methode zur Benutzerauthentifizierung und schützt auch nicht in irgendeiner Weise die Entität, die im Klartext über das physische Netzwerk übertragen wird. HTTP verhindert nicht, dass zusätzliche Authentifizierungsschemata und Verschlüsselungsmechanismen verwendet werden, um die Sicherheit zu erhöhen oder Verbesserungen (wie Schemata zur Verwendung von Einmalpasswörtern) zur Basis-Authentifizierung hinzuzufügen.
Der schwerwiegendste Mangel der Basis-Authentifizierung ist, dass sie im Wesentlichen zur Klartextübertragung des Benutzerpassworts über das physische Netzwerk führt. Dies ist das Problem, das die Digest-Authentifizierung (Digest Authentication) zu lösen versucht.
Da die Basis-Authentifizierung die Klartextübertragung von Passwörtern beinhaltet, sollte sie nicht (ohne Verbesserungen) verwendet werden, um sensible oder wertvolle Informationen zu schützen.
Eine häufige Verwendung der Basis-Authentifizierung dient Identifikationszwecken -- vom Benutzer zu verlangen, einen Benutzernamen und ein Passwort als Identifikationsmittel bereitzustellen, zum Beispiel zum Sammeln genauer Nutzungsstatistiken auf einem Server. Wenn sie auf diese Weise verwendet wird, ist es verlockend zu denken, dass ihre Verwendung keine Gefahr darstellt, wenn unbefugter Zugriff auf die geschützten Dokumente kein Hauptanliegen ist. Dies ist nur richtig, wenn der Server sowohl Benutzernamen als auch Passwort an die Benutzer ausgibt und insbesondere dem Benutzer nicht erlaubt, sein eigenes Passwort zu wählen. Die Gefahr besteht darin, dass naive Benutzer häufig ein einziges Passwort wiederverwenden, um die Aufgabe der Verwaltung mehrerer Passwörter zu vermeiden.
Wenn ein Server Benutzern erlaubt, ihre eigenen Passwörter auszuwählen, besteht die Bedrohung nicht nur im unbefugten Zugriff auf Dokumente auf dem Server, sondern auch im unbefugten Zugriff auf alle anderen Ressourcen auf anderen Systemen, die der Benutzer mit demselben Passwort schützt. Darüber hinaus können in der Passwortdatenbank des Servers viele der Passwörter auch die Passwörter der Benutzer für andere Sites sein. Der Eigentümer oder Administrator eines solchen Systems könnte daher alle Benutzer des Systems dem Risiko unbefugten Zugriffs auf all diese anderen Sites aussetzen, wenn diese Informationen nicht auf sichere Weise verwaltet werden.
Die Basis-Authentifizierung ist auch anfällig für Spoofing durch gefälschte Server. Wenn ein Benutzer glauben gemacht werden kann, dass er sich mit einem Host verbindet, der durch Basis-Authentifizierung geschützte Informationen enthält, während er sich tatsächlich mit einem feindlichen Server oder Gateway verbindet, kann der Angreifer ein Passwort anfordern, es zur späteren Verwendung speichern und einen Fehler vortäuschen. Diese Art von Angriff ist mit Digest-Authentifizierung nicht möglich. Server-Implementierer sollten sich gegen die Möglichkeit dieser Art von Fälschung durch Gateways oder CGI-Skripte schützen.
4.2 Authentifizierung von Clients mit Digest-Authentifizierung (Authentication of Clients using Digest Authentication)
Die Digest-Authentifizierung (Digest Authentication) bietet im Vergleich zu Public-Key-basierten Mechanismen keinen starken Authentifizierungsmechanismus.
Sie ist jedoch deutlich stärker als (zum Beispiel) CRAM-MD5, das für die Verwendung mit LDAP [10], POP und IMAP vorgeschlagen wurde (siehe RFC 2195 [9]). Sie ist dazu bestimmt, den viel schwächeren und noch gefährlicheren Basis-Mechanismus zu ersetzen.
Die Digest-Authentifizierung bietet keinen Vertraulichkeitsschutz außer dem Schutz des tatsächlichen Passworts. Der gesamte Rest der Anfrage und Antwort ist für einen Abhörenden verfügbar.
Die Digest-Authentifizierung bietet nur begrenzten Integritätsschutz für die Nachricht in beide Richtungen. Wenn der qop=auth-int-Mechanismus verwendet wird, sind die Nachrichtenteile geschützt, die zur Berechnung der WWW-Authenticate- und Authorization-Header-Feld-Response-Direktivwerte verwendet werden (siehe Abschnitt 3.2 oben). Die meisten Header-Felder und ihre Werte können als Teil eines Man-in-the-Middle-Angriffs modifiziert werden.
Die Digest-Authentifizierung kann die Anforderungen vieler sicherer HTTP-Transaktionen nicht erfüllen. Für diese Anforderungen sind TLS oder SHTTP geeignetere Protokolle. Insbesondere kann die Digest-Authentifizierung nicht für Transaktionen verwendet werden, für die Vertraulichkeitsschutz erforderlich ist. Dennoch ist die Digest-Authentifizierung sowohl nützlich als auch für viele Funktionen geeignet. Jeder Dienst, der derzeit Basis-Authentifizierung verwendet, sollte so bald wie praktikabel auf Digest-Authentifizierung umsteigen.
4.3 Nonce-Werte mit begrenzter Verwendung (Limited Use Nonce Values)
Das Digest-Schema verwendet einen vom Server spezifizierten Nonce, um die Generierung des Request-Digest-Werts zu initiieren (wie in Abschnitt 3.2.2.1 oben spezifiziert). Wie im Beispiel-Nonce in Abschnitt 3.2.1 gezeigt, steht es dem Server frei, den Nonce so zu konstruieren, dass er nur von einem bestimmten Client, für eine bestimmte Ressource, für einen begrenzten Zeitraum oder eine Anzahl von Verwendungen oder andere Einschränkungen verwendet werden kann. Dies verstärkt den gebotenen Schutz gegen beispielsweise Replay-Angriffe (siehe 4.5). Es sollte jedoch beachtet werden, dass die für die Generierung und Überprüfung des Nonce gewählte Methode auch Auswirkungen auf Leistung und Ressourcen hat.
4.4 Vergleich von Digest mit Basis-Authentifizierung (Comparison of Digest with Basic Authentication)
Sowohl Digest- als auch Basis-Authentifizierung sind schwach in dem Sinne, dass sie möglicherweise nicht den unbefugten Zugriff durch einen entschlossenen Gegner verhindern. Der Vergleich zwischen beiden zeigt jedoch den Nutzen und vielleicht sogar die Notwendigkeit, Basis durch Digest zu ersetzen.
Für die Art von Transaktionen, für die dieses Protokoll wahrscheinlich verwendet wird, ist die größte Bedrohung das Abhören des Netzwerks. Diese Art von Transaktion könnte beispielsweise den Online-Zugriff auf eine Datenbank umfassen, deren Nutzung auf zahlende Abonnenten beschränkt ist. Mit Basis-Authentifizierung kann ein Abhörender das Passwort des Benutzers erhalten. Dies erlaubt ihm nicht nur den Zugriff auf alles in der Datenbank, sondern, was oft schlimmer ist, den Zugriff auf alles andere, was der Benutzer mit demselben Passwort schützt.
Im Gegensatz dazu erhält der Abhörende mit Digest-Authentifizierung nur Zugriff auf die betreffende Transaktion und nicht auf das Passwort des Benutzers. Die vom Abhörenden erhaltenen Informationen würden einen Replay-Angriff ermöglichen, aber nur mit derselben Dokumentanforderung, und selbst das kann durch die Nonce-Wahl des Servers eingeschränkt werden.
4.5 Replay-Angriffe (Replay Attacks)
Replay-Angriffe mit Digest-Authentifizierung sind typischerweise für einfache GET-Anfragen bedeutungslos, da der Abhörende das einzige Dokument, das er durch Wiederholung erhalten könnte, bereits gesehen hat. Dies liegt daran, dass die URI des angeforderten Dokuments in der Client-Anfrage gehasht wird und der Server nur dieses Dokument liefern wird. Im Gegensatz dazu steht unter Basis-Authentifizierung, sobald der Abhörende das Passwort des Benutzers hat, jedes durch dieses Passwort geschützte Dokument ihm offen.
Daher ist es für einige Zwecke notwendig, sich gegen Replay-Angriffe zu schützen. Gute Digest-Implementierungen können dies auf verschiedene Weise tun. Der vom Server erstellte "Nonce"-Wert ist implementierungsabhängig, aber wenn er einen Hash der Client-IP, einen Zeitstempel, das Ressourcen-ETag und einen privaten Serverschlüssel enthält (wie oben empfohlen), ist ein Replay-Angriff nicht einfach.
Für Anwendungen, die nicht einmal die Möglichkeit von Replay-Angriffen tolerieren können, kann der Server Einmal-Nonce-Werte verwenden, die nicht ein zweites Mal akzeptiert werden. Dies erfordert den Overhead, dass der Server sich daran erinnert, welche Nonce-Werte verwendet wurden, bis der Nonce-Zeitstempel abläuft.
4.6 Schwäche durch mehrere Authentifizierungsschemata (Weakness Created by Multiple Authentication Schemes)
Wenn ein Server mehrere Authentifizierungsschemata im WWW-Authenticate-Header anbietet, sollte der Client das stärkste Schema auswählen, das er unterstützt. Wenn jedoch ein Angreifer die Antwort ändern kann, um das stärkere Schema zu entfernen, kann der Client gezwungen werden, ein schwächeres Schema zu verwenden.
4.7 Online-Wörterbuch-Angriffe (Online dictionary attacks)
Wenn der Server die Rate der Authentifizierungsversuche nicht begrenzt, kann ein Angreifer eine große Anzahl von Passwörtern ausprobieren, um das richtige zu erraten. Server sollten die Rate fehlgeschlagener Authentifizierungsversuche von einer einzelnen IP-Adresse begrenzen.
4.8 Man-in-the-Middle
Die Digest-Authentifizierung ist anfällig für Man-in-the-Middle-Angriffe. Ein Angreifer kann die Kommunikation zwischen Client und Server abfangen und Nachrichten ändern oder ersetzen. Die Verwendung von TLS oder anderen Transport-Layer-Sicherheitsmechanismen kann solche Angriffe verhindern.
4.9 Angriffe mit gewähltem Klartext (Chosen plaintext attacks)
Die Digest-Authentifizierung ist anfällig für Angriffe mit gewähltem Klartext. Ein Angreifer kann bestimmte URIs wählen und die resultierenden Hashes beobachten, wodurch er möglicherweise Informationen über das Passwort erhält.
4.10 Vorberechnete Wörterbuch-Angriffe (Precomputed dictionary attacks)
Wenn ein Angreifer auf die Passwortdatei des Servers zugreifen kann, kann er Hashes häufiger Passwörter vorberechnen und diese Hashes dann mit denen in der Datei vergleichen. Die Verwendung von Salt-Werten kann diesen Angriff erschweren.
4.11 Batch-Brute-Force-Angriffe (Batch brute force attacks)
Wenn ein Angreifer mehrere Authentifizierungsaustausche erfassen kann, kann er versuchen, das Passwort offline mit Brute-Force zu knacken. Die Verwendung starker Passwörter und die Begrenzung der Gültigkeitsdauer von Nonces können dieses Risiko mindern.
4.12 Spoofing durch gefälschte Server (Spoofing by Counterfeit Servers)
Clients sollten die Identität des Servers überprüfen, um zu verhindern, dass sie sich mit gefälschten Servern verbinden. Die Verwendung von TLS mit Serverzertifikatsvalidierung kann solche Angriffe verhindern.
4.13 Speichern von Passwörtern (Storing passwords)
Server sollten Passwörter nicht im Klartext speichern. Stattdessen sollte der Hash des Passworts gespeichert werden. Für die Digest-Authentifizierung kann der Server H(username:realm:password) speichern, was die Überprüfung des Clients ermöglicht, ohne Klartextpasswörter zu speichern.
4.14 Zusammenfassung (Summary)
Die Digest-Authentifizierung bietet bessere Sicherheit als die Basis-Authentifizierung, ist aber keine vollständige Sicherheitslösung. Für Anwendungen, die starke Sicherheit erfordern, sollten TLS oder andere stärkere Sicherheitsmechanismen verwendet werden. Dennoch ist die Digest-Authentifizierung eine praktische und nützliche Verbesserung für viele Anwendungen.