Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

What encoding should I use for HTTP Basic Authentication?

The RFC2617 says to encode the username and password to base64 but don't say what character encoding to use when creating the octets for input into the base64 algorithm.

Should I assume US-ASCII or UTF8? Or has someone settled this question somewhere already?

like image 432
Dobes Vandermeer Avatar asked Aug 30 '11 11:08

Dobes Vandermeer


People also ask

How is basic authentication encoded?

Basic Authentication sends a Base64 encoded string that contains a user name and password for the client via HTTP headers. Base64 is not a form of encryption and should be considered the same as sending the user name and password in clear text. However, all traffic is encrypted and transmitted over a TLS v1.

Does Basic Auth use Base64?

Basic authentication is a simple username and password scheme built into the HTTP protocol. Workflows sends HTTP requests with the Authorization header containing the word Basic followed by a space and a base64 encoded string of username:password .

Why does Basic Auth use Base64?

The Base64 encoding, most importantly, ensures that the user:pass characters are all part of the ASCII character set and ASCII encoded. A user:pass in HTTP Basic auth is part of the Authorization header-field value. HTTP header values are ASCII (or Extended ASCII) encoded/decoded.

Is HTTP Basic Auth encrypted?

Basic authentication is vulnerable to replay attacks. Because basic authentication does not encrypt user credentials, it is important that traffic always be sent over an encrypted SSL session.


1 Answers

Original spec - RFC 2617

RFC 2617 can be read as "ISO-8859-1" or "undefined". Your choice. It's known that many servers use ISO-8859-1 (like it or not) and will fail when you send something else. So probably the only safe choice is to stick to ASCII.

For more information and a proposal to fix the situation, see the draft "An Encoding Parameter for HTTP Basic Authentication" (which formed the basis for RFC 7617).

New - RFC 7617

Since 2015 there is RFC 7617, which obsoletes RFC 2617. In contrast to the old RFC, the new RFC explicitly defines the character encoding to be used for username and password.

  • The default encoding is still undefined. Is is only required to be compatible with US-ASCII (meaning it maps ASCII bytes to ASCII bytes, like UTF-8 does).
  • The server can optionally send an additional authentication parameter charset="UTF-8" in its challenge, like this:
    WWW-Authenticate: Basic realm="myChosenRealm", charset="UTF-8"
    This announces that the server will accept non-ASCII characters in username / password, and that it expects them to be encoded in UTF-8 (specifically Normalization Form C). Note that only UTF-8 is allowed.

Complete version:

Read the spec. It contains additional details, such as the exact encoding procedure, and the list of Unicode codepoints that should be supported.

Browser support

As of 2018, modern browsers will usually default to UTF-8 if a user enters non-ASCII characters for username or password (even if the server does not use the charset parameter).

  • Chrome also appears to use UTF-8
  • Internet Explorer does not use UTF-8 (issue #11879588 )
  • Firefox is experimenting with a change currently planned for v59 (bug 1419658)

Realm

The realm parameter still only supports ASCII characters even in RFC 7617.

like image 153
Julian Reschke Avatar answered Nov 11 '22 01:11

Julian Reschke