Welche Codierung sollte ich für die HTTP-Standardauthentifizierung verwenden?

Der RFC2617 sagt, den Benutzernamen und das Passwort zu Base64 zu kodieren, aber nicht zu sagen, welche Zeichencodierung beim Erstellen der Oktette für die Eingabe in den base64-Algorithmus verwendet werden soll.

Sollte ich US-ASCII oder UTF8 annehmen? Oder hat jemand diese Frage schon irgendwo geklärt?

Solutions Collecting From Web of "Welche Codierung sollte ich für die HTTP-Standardauthentifizierung verwenden?"

Originalspezifikation – RFC 2617

RFC 2617 kann als “ISO-8859-1” oder “undefined” gelesen werden. Deine Entscheidung. Es ist bekannt, dass viele Server ISO-8859-1 verwenden (wie es oder nicht) und wird fehlschlagen, wenn Sie etwas anderes senden. Wahrscheinlich ist die einzige sichere Wahl, sich an ASCII zu halten.

Weitere Informationen und einen Vorschlag zum Beheben der Situation finden Sie im Entwurf “Ein Codierungsparameter für die HTTP-Basisauthentifizierung” (der die Grundlage für RFC 7617 bildete).

Neu – RFC 7617

Seit 2015 gibt es RFC 7617 , das RFC 2617 veraltet. Im Gegensatz zum alten RFC definiert der neue RFC explizit die Zeichencodierung, die für Benutzername und Passwort verwendet werden soll.

  • Die Standardcodierung ist noch nicht definiert. Es muss nur mit US-ASCII kompatibel sein (dh ASCII-Bytes werden wie ASCII-Bytes abgebildet, wie UTF-8).
  • Der Server kann in seiner Challenge optional einen zusätzlichen Authentifizierungsparameter charset="UTF-8" senden:
    WWW-Authenticate: Basic realm="myChosenRealm", charset="UTF-8"
    Dies kündigt an, dass der Server Nicht-ASCII-Zeichen in Benutzername / Passwort akzeptiert und erwartet, dass sie in UTF-8 (speziell Normalisierungsform C) codiert sind. Beachten Sie, dass nur UTF-8 erlaubt ist.

Vollständige Version:

Lesen Sie die Spezifikation . Enthält zusätzliche Details, z. B. die genaue Codierungsprozedur und die Liste der Unicode-Codepoints, die unterstützt werden sollen.

Browserunterstützung

Ab 2018 verwenden moderne Browser standardmäßig UTF-8, wenn ein Benutzer Nicht-ASCII-Zeichen für Benutzername oder Kennwort eingibt (auch wenn der Server den Parameter charset nicht verwendet).

  • Chrome scheint auch UTF-8 zu verwenden
  • Internet Explorer verwendet UTF-8 nicht ( Problem # 11879588 )
  • Firefox experimentiert mit einer Änderung, die derzeit für v59 geplant ist ( Bug 1419658 )

Reich

Der Realm- Parameter unterstützt nur ASCII-Zeichen auch in RFC 7617.

Kurze Antwort: iso-8859-1, es sei denn, codierte Wörter werden gemäß RFC2047 (MIME) verwendet.

Längere Erklärung:

RFC2617, Abschnitt 2 (HTTP-Authentifizierung) definiert grundlegende Anmeldeinformationen :

 basic-credentials = base64-user-pass base64-user-pass =  user-pass = userid ":" password userid = * password = *TEXT 

Die Spezifikation sollte nicht ohne Bezugnahme auf RFC2616 (HTTP 1.1) für Definitionen in BNF gelesen werden (wie oben):

Diese Spezifikation ist eine Ergänzung zur HTTP / 1.1-Spezifikation 2 . Es verwendet den erweiterten BNF-Abschnitt 2.1 dieses Dokuments und stützt sich sowohl auf die in diesem Dokument definierten Nicht-Terminals als auch auf andere Aspekte der HTTP / 1.1-Spezifikation.

RFC2616, Abschnitt 2.1 definiert TEXT (Hervorhebung meins):

Die TEXT-Regel wird nur für beschreibende Feldinhalte und Werte verwendet, die nicht vom Nachrichtenparser interpretiert werden sollen. Wörter von * TEXT dürfen nur Zeichen aus anderen Zeichensätzen als ISO-8859-1 enthalten , wenn sie gemäß den Regeln von RFC 2047 codiert sind.

 TEXT =  

Es ist also definitiv iso-8859-1, es sei denn, Sie entdecken eine andere Codierung nach RFC2047 (MIME pt. 3) Regeln:

 // Username: Mike // Password T€ST Mike:=?iso-8859-15?q?T€ST?= 

In diesem Fall würde das Euro-Zeichen in dem Wort als 0xA4 gemäß iso-8859-15 codiert werden. Es ist mein Verständnis, dass Sie nach diesen codierten Worttrennzeichen suchen und dann die Wörter im Inneren basierend auf der angegebenen Codierung dekodieren sollten. Wenn Sie dies nicht tun, werden Sie denken, das Passwort sei =?iso-8859-15?q?T¤ST?= ( 0xA4 , dass 0xA4 bei der Interpretation als iso-8859-1 zu =?iso-8859-15?q?T¤ST?= 0xA4 würde).

Dies ist mein Verständnis, ich kann keine explizitere Bestätigung als diese RFCs finden. Und einige davon scheinen widersprüchlich. Zum Beispiel ist eines der 4 erklärten Ziele von RFC2047 (MIME, Punkt 3) neu zu definieren:

das Format von Nachrichten, um … Textkopfinformationen in anderen Zeichensätzen als US-ASCII zu ermöglichen.

Aber RFC2616 (HTTP 1.1) definiert einen Header mit der TEXT-Regel, die standardmäßig auf iso-8859-1 verweist. Bedeutet das, dass jedes Wort in diesem Header ein codiertes Wort sein sollte (dh das =?...?= Formular)?

Auch relevant, kein aktueller Browser tut dies. Sie verwenden utf-8 (Chrome, Opera), iso-8859-1 (Safari), die System-Codepage (IE) oder etwas anderes (wie nur das wichtigste Bit von utf-8 im Fall von Firefox).

Edit: Ich habe gerade festgestellt, dass diese Antwort das Problem eher aus der serverseitigen Perspektive betrachtet.

Wenn Sie interessiert sind, was Browser tun, wenn Sie nicht-ASCII-Zeichen an der Login-Eingabeaufforderung eingeben, habe ich gerade mit Firefox versucht.

Es scheint, faul umzusetzen Everything zu ISO-8859-1, indem das niedrigstwertige Byte von jedem Unicode-Wert nimmt, zB:

 User: 豚 (\u8c5a) Password: 虎 (\u864e) 

Sind wie folgt codiert:

 User: Z (\u005a) Password: N (\u004e) 

0x5a 0x3a 0x4e base64-> WjpO

RFCs beiseite, im Spring-Framework die BasicAuthenticationFilter class, der Standardwert ist UTF-8 .

Der Grund für diese Wahl ist meiner Meinung nach, dass UTF-8 in der Lage ist, alle möglichen Zeichen zu codieren, während ISO-8859-1 (oder ASCII) dies nicht ist. Der Versuch, Benutzernamen / Passwort mit Zeichen zu verwenden, die nicht im System unterstützt werden, kann zu errorshaftem Verhalten oder (möglicherweise schlechteren) Sicherheitseinbußen führen.