4. Sicherheitsüberlegungen
Das Basic-Authentifizierungsschema ist keine sichere Methode zur Benutzerauthentifizierung und schützt auch in keiner Weise die Entität, die im Klartext über das physische Netzwerk übertragen wird, das als Träger verwendet wird. HTTP verhindert nicht das Hinzufügen von Erweiterungen (wie Schemata zur Verwendung von Einmalpasswörtern) zur Basic-Authentifizierung.
Der schwerwiegendste Fehler der Basic-Authentifizierung besteht darin, dass sie zur Klartextübertragung des Benutzerpassworts über das physische Netzwerk führt. Viele andere Authentifizierungsschemata behandeln dieses Problem.
Da die Basic-Authentifizierung die Klartextübertragung von Passwörtern beinhaltet, SOLLTE sie NICHT (ohne Erweiterungen wie HTTPS [RFC2818]) zum Schutz sensibler oder wertvoller Informationen verwendet werden.
Eine häufige Verwendung der Basic-Authentifizierung ist für Identifikationszwecke -- das Erfordernis, dass der Benutzer eine Benutzer-ID und ein Passwort als Identifikationsmittel bereitstellt, beispielsweise zum Sammeln genauer Nutzungsstatistiken auf einem Server. Wenn sie auf diese Weise verwendet wird, ist es verlockend zu denken, dass keine Gefahr bei ihrer Verwendung besteht, wenn der unerlaubte Zugriff auf die geschützten Dokumente kein Hauptanliegen ist. Dies ist nur korrekt, wenn der Server sowohl Benutzer-ID als auch Passwort an die Benutzer ausgibt und insbesondere dem Benutzer nicht erlaubt, sein eigenes Passwort zu wählen. Die Gefahr entsteht, weil 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, dann ist die Bedrohung nicht nur unbefugter Zugriff auf Dokumente auf dem Server, sondern auch unbefugter Zugriff auf alle anderen Ressourcen auf anderen Systemen, die der Benutzer mit demselben Passwort schützt. Darüber hinaus können in der Passwort-Datenbank des Servers viele der Passwörter auch 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 eines unbefugten Zugriffs auf all diese anderen Sites aussetzen, wenn diese Informationen nicht auf sichere Weise gepflegt werden. Dies wirft sowohl Sicherheits- als auch Datenschutzbedenken auf ([RFC6973]). Wenn dieselbe Benutzer-ID/Passwort-Kombination für den Zugriff auf andere Konten verwendet wird, wie z.B. ein E-Mail- oder Gesundheitsportalkonto, könnten persönliche Informationen offengelegt werden.
Die Basic-Authentifizierung ist auch anfällig für Spoofing durch gefälschte Server. Wenn ein Benutzer dazu gebracht werden kann zu glauben, dass er sich mit einem Host verbindet, der durch Basic-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 für spätere Verwendung speichern und einen Fehler vortäuschen. Server-Implementierer sollten sich vor dieser Art von Fälschung schützen; insbesondere sollten Softwarekomponenten, die die Kontrolle über das Nachrichten-Framing bei einer bestehenden Verbindung übernehmen können, vorsichtig oder gar nicht verwendet werden (zum Beispiel: NPH ("Non-Parsed Header") Skripte wie in Abschnitt 5 von [RFC3875] beschrieben).
Server und Proxys, die Basic-Authentifizierung implementieren, müssen Benutzerpasswörter in irgendeiner Form speichern, um eine Anfrage zu authentifizieren. Diese Passwörter sollten so gespeichert werden, dass ein Leck der Passwortdaten sie nicht trivial wiederherstellbar macht. Dies ist besonders wichtig, wenn Benutzer ihre eigenen Passwörter festlegen dürfen, da Benutzer bekanntermaßen schwache Passwörter wählen und diese über Authentifizierungs-Realms hinweg wiederverwenden. Während eine vollständige Diskussion guter Passwort-Hashing-Techniken über den Rahmen dieses Dokuments hinausgeht, sollten Server-Betreiber Anstrengungen unternehmen, um die Risiken für ihre Benutzer im Falle eines Passwortdaten-Lecks zu minimieren. Zum Beispiel sollten Server vermeiden, Benutzerpasswörter im Klartext oder als ungesalzene Digests zu speichern. Für weitere Diskussionen über moderne Passwort-Hashing-Techniken siehe den "Password Hashing Competition" (https://password-hashing.net).
Die Verwendung des UTF-8-Zeichenkodierungsschemas und der Normalisierung führt zu zusätzlichen Sicherheitsüberlegungen; siehe Abschnitt 10 von [RFC3629] und Abschnitt 6 von [RFC5198] für weitere Informationen.