Hallo Rüdiger,
Warum unterstützt der Browser Chrome nur 7bit-Zeichen bei mit .htaccess geschützten Ordnern?
Ist das ein Bug? Oder nur das Unvermögen mancher Leute, die Realitäten zu begreifen?
Ich nehme an, du meinst non-ASCII Zeichen in der HTTP Authentication? Das ist aber nicht Chrome-spezifisch, das ist generell ein Problem, wenn Client und Server unterschiedliches Encoding verwenden. Das Encoding der ersten 128 Zeichen erfolgt überall nach ASCII[1] und macht deshalb keine Probleme, ab dann beginnt das Niemandsland von ISO-8859-? und Unicode. RFC 2617 definiert keine Möglichkeit, das Encoding des Authorization-Headers zu spezifizieren, das liefert erst der Nachfolger, RFC 7617.
Der definiert, dass der Server WWW-Authenticate: Basic realm="foo", charset="UTF-8" liefern und damit verlangen kann, dass die Credentials UTF-8 verwenden bevor sie base64-codiert werden.
Dabei wäre 8bit deutlich sicherer.
HTTP Authentication ist eh nicht sicher. Richtige Sicherheit geht anders.
Die Bittigkeit des Zeichensatzes ist kein Kriterium für Sicherheit, nur die Entropie des Passworts. Ein 8-bit Zeichensatz bietet eine hypothetische Entropie von 7,7 Bits pro Stelle (de facto weniger, weil nicht alle Zeichen auf der Tastatur sind und daher eher nicht verwendet werden). Im 7-bit Zeichensatz sind es 6,6 Bits, es reicht also, wenn ich mein Passwort 2 Zeichen länger mache und die Bittigkeit ist ausgeglichen.
Aber 8 Bit-Zeichensätze retten Dich nicht, wenn der Anwender in China sitzt. Oder Russland. Oder sonstwo, wo die Zeichen jenseits des Codepoints 255 codiert werden. RFC 7617 kann UTF-8 aktivieren, und damit kämst Du sinnvoll weiter.
Es passen sich sogar Browser an und können jetzt auch keine 8bit-Zeichen mehr.
Vielleicht weil sie RFC7617 umsetzen und UTF-8 wollen statt ISO-8859-1?
Aber ich spekuliere eh nur. Ich mache keine HTTP Authentication.
Rolf
sumpsi - posui - obstruxi
von EBCDIC-Hosts mal abgesehen ↩︎