The 'charset' parameter is advisory only (not mandatory on the client) and is defined only in challenges, not in credentials, because the credentials use the non-extensible token68 syntax. Switching the default to UTF-8 was rejected because sites using legacy encodings (ISO-8859-1) would break.

http

The default character encoding for user-pass is intentionally left undefined (as long as it is US-ASCII compatible) for backwards compatibility, because existing implementations used either locale-specific encodings like ISO-8859-1 or UTF-8, and mandating UTF-8 would break sites expecting the legacy encoding.

http

The parameter name 'charset' was chosen for consistency with RFC 2831 Section 2.1.1; the authors note that 'accept-charset' would have been a more accurate name since it expresses the server's expectation rather than describing the message it appears in.

http

The 'realm' parameter can carry textual data but RFC 7235 does not define a way to reliably transport non-US-ASCII characters in realm values; this is a known limitation requiring a future revision to RFC 7235.

http

User-ids or passwords containing non-US-ASCII characters will cause interoperability issues unless both parties agree on a character encoding scheme. The 'charset=UTF-8' parameter increases the likelihood that clients will switch to UTF-8, but servers may need to fall back to legacy encodings to accommodate older clients.

http

A client SHOULD assume that resources identified by URIs with a prefix-match of the authentication scope (the URI up to and including the last slash of the path) are within the same protection space, and MAY preemptively send credentials without a new challenge.

http

A user-id containing a colon character is invalid because the first colon in the user-pass string separates user-id from password; user-ids with colons cannot be encoded in user-pass strings.

http

Basic authentication SHOULD NOT be used without enhancements such as HTTPS to protect sensitive or valuable information, because it transmits passwords in cleartext over the network.

http, security, tls

For password when 'charset=UTF-8' is in effect, recipients MUST support all characters defined in the 'OpaqueString' profile (RFC 7613 Section 4.2).

http, security

For user-id when 'charset=UTF-8' is in effect, recipients MUST support all characters in the 'UsernameCasePreserved' profile (RFC 7613 Section 3.3), except the colon character.

http, security

The user-id and password MUST NOT contain any control characters (CTL as defined in RFC 5234 Appendix B.1).

http, security

If users choose their own passwords and reuse them across sites, a server's password database may expose users' credentials for other systems (email, health portals, etc.), raising both security and privacy concerns per RFC 6973.

http, security, privacy

The Basic authentication scheme requires the 'realm' authentication parameter in challenges (REQUIRED) and optionally supports the 'charset' parameter. Unknown parameters MUST be ignored by recipients, and new parameters can only be defined by revising this specification.

http, security

The 'charset' authentication parameter, usable only in challenges, allows servers to indicate their preferred character encoding for the user-pass octet sequence. The only allowed value is "UTF-8" (case-insensitive), indicating NFC normalization followed by UTF-8 encoding.

http

The IANA 'Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry' (maintained per RFC 7235) entry for the 'Basic' authentication scheme has been updated to reference RFC 7617.

http, registry

Basic authentication is vulnerable to server spoofing: an attacker posing as a legitimate server can solicit and capture the user's password. Software components that take over message framing on an existing connection (e.g., NPH scripts) need to be used carefully or not at all.

http, security

Servers storing user passwords for Basic authentication ought to avoid plaintext or unsalted digest storage; a leak of the password database should not make passwords trivially recoverable, especially since users reuse passwords across realms.

http, security

The most serious flaw of Basic authentication is cleartext transmission of passwords. It is not a secure authentication method unless used over a secure transport such as TLS.

http, security, tls

Use of UTF-8 encoding and NFC normalization introduces additional security considerations; see RFC 3629 Section 10 and RFC 5198 Section 6 for details on encoding-related attacks.

http, security

Credentials are constructed by concatenating the user-id, a colon (":"), and the password to form 'user-pass', encoding it as an octet sequence, then Base64-encoding the result (RFC 4648 Section 4) to produce a US-ASCII token68 value placed in the Authorization header field.

http, security