Basic Authentication Credentials are Encrypted with TLS

You may have heard claims that HTTP “basic” authentication (classic user/password popup prompt or via an API call) leaves credentials unencrypted and exposed. While it’s true that basic auth itself doesn’t encrypt credentials, this doesn’t matter in practice.

Modern sites and APIs should be using HTTPS, which encrypts everything over the wire, protecting basic authentication credentials in transit. This article will explain why that’s the case.

A quick overview of HTTP authentication

The way HTTP authentication works is via standard headers. We recommend the Mozilla Developer Network (MDN) documentation if you want to learn more, but to summarize: when the client contacts a server configured with native HTTP authentication, the server replies with an HTTP 401 (Unauthorized) status, along with a header (WWW-Authorize) about how to authenticate. The client responds with a header containing credentials (Authorization). The server then determines if the authentication passes or fails.

Basic authentication is one of the authentication types available with native HTTP authentication. (There are other kinds, but we’re talking about basic authentication today.) Basic authentication simply encodes a username and password in Base64, which ensures that any strange characters don’t cause any problems in the header—it isn’t a form of encryption or obfuscation. For example, the example “YWxhZGRpbjpvcGVuc2VzYW1l” from MDN decodes as “aladdin:opensesame“.

You’ll notice MDN has a big warning:

Warning: The “Basic” authentication scheme […] sends the credentials encoded but not encrypted. This would be completely insecure unless the exchange was over a secure connection (HTTPS/TLS).

However, the last sentence is crucial—this is a problem only over plain HTTP. HTTPS is pretty much standard for the public internet (and you should consider it for your intranet too), so the phrasing here hides some details for the end.

Cakes have layers

HTTP is layered on top of other protocols. Most commonly, it’s paired with Transport Layer Security (TLS), the successor to the classic Secure Sockets Layer (SSL). TLS provides transparent encryption to protocols that sit on top of it. With TLS, HTTP becomes HTTPS and the entire HTTP session is encrypted—including the authentication challenge. There is no out-of-band way it can expose the credentials that would ruin the security of the connection.

You can prove this yourself with a tool that snoops on connections like Wireshark. Starting with this unencrypted (HTTP) example, you can plainly see the headers from the client and server.

An HTTP session transcript in Wireshark, with a failed authentication, then a successful one

Compare with a TLS session (HTTPS), where the client and server negotiate parameters for encryption, then the rest of the session is opaque binary data. It’s theoretically possible to decrypt this from Wireshark, but you would need to exfiltrate the keys from either end of the session—not something the average attacker could easily do.

Wireshark showing an encrypted TLS session

Encryption also holds for all the other headers. Every time you log into a TLS-protected (HTTPS) website with a login form using form bodies and cookies, or connect to an API via HTTPS, those elements are also encrypted over the wire.

Where basic authentication fits; alternatives

While TLS does protect basic authentication data in transit, nowadays basic authentication is used mostly for specialized purposes: either for very simple scenarios or in combination with other authentication mechanisms, such as to retrieve a token from an authentication API.

Basic authentication can be awkward for website end-users (how do I log out?) and one should always consider the general security implications of passwords (what if the password is phished via social engineering?). The debate over passwords is better covered elsewhere, but do consider:

• If you have Kerberos-based SSO infrastructure (i.e. Active Directory), you can reuse this for your application. With EIM set up on your IBM i, Apache can be made to use it.
• For a user-facing application, HTTP authentication is rarely the right decision. You should be using form-based authentication, or adopt passkeys, the new authentication standard promoted by browser vendors.
• For a back-end service such as an API, bearer tokens (which can work with HTTP authentication) in a format like JWT provide more granular security.

When you use TLS/HTTPS, all your communications, including authentication credentials, get a layer of protection. Ultimately, your decisions about authentication, and security in general, should be based on what makes sense for your application and the APIs or services you use.