HTTP authentication under the microscope

During a recent networking and cybersecurity lab, I worked on setting up an Apache web server and studying how HTTP authentication mechanisms behave during a man-in-the-middle (MITM) attack using Burp Suite and FoxyProxy.

The objective was not only to configure a working web server, but also to understand how authentication protocols can be manipulated when communications are intercepted.

Setting up the Apache environment

The lab was built on a Linux machine using Apache2.

After installing Apache, two local virtual hosts were configured:

• libre.local
• prive.local

These domains were mapped to the loopback address using /etc/hosts:

Local virtual host mapping using /etc/hosts

127.0.0.1 libre.local
127.0.0.1 prive.local

The environment included:

• a public area
• an IP-restricted directory
• a Basic authentication zone
• a Digest authentication zone

This allowed us to simulate multiple access-control scenarios locally.

Understanding Basic vs Digest authentication

The first part of the lab focused on comparing two HTTP authentication mechanisms.

Basic Authentication

Basic authentication sends credentials using Base64 encoding:

Authorization: Basic base64(username:password)

Even though the credentials appear transformed, Base64 is only an encoding mechanism, not encryption.

Anyone intercepting the traffic can easily recover the original username and password.

Digest Authentication

Digest authentication is more secure because the password itself is never transmitted directly.

Instead:

• the server sends a challenge (nonce)
• the client computes a hash response using:
• username
• password
• nonce
• HTTP method
• requested URI

This creates a challenge-response authentication mechanism.

Configuration of the protected virtual host

Setting up the MITM environment

To intercept traffic, the browser was configured with FoxyProxy to redirect HTTP requests through Burp Suite running locally on:

127.0.0.1:8080

Routing browser traffic through Burp Suite using FoxyProxy

Traffic flow became:

Browser ↔ Burp Suite ↔ Apache Server

This allowed full inspection and modification of HTTP traffic.

Intercepting the Digest authentication challenge

When accessing:

http://prive.local/digest

Apache responded with:

Intercepting the Digest authentication challenge

401 Unauthorized
WWW-Authenticate: Digest

Using Burp Suite, the server response was intercepted before reaching the browser.

Downgrading Digest to Basic

The most important part of the experiment was the manipulation of the authentication negotiation process.

Using Burp Suite, this response was intercepted before reaching the browser. The following header:

The original header:

WWW-Authenticate: Digest ...

was identified in the intercepted response.

The header was then modified and replaced with:

WWW-Authenticate: Basic realm="DigestAuth"

The browser then believed the server requested Basic authentication instead of Digest.

As a result, it sent:

Authorization: Basic ...

The intercepted value was encoded in Base64 and could be decoded to recover the username and password.

This manipulation demonstrates a downgrade attack where the authentication negotiation is modified in order to force the client to use a weaker authentication mechanism.

Handling the server response and understanding the 401 error

During the experiment, the server responded with:

401 Unauthorized

This behavior is expected.

Even though the client was forced to switch to Basic authentication, the server was still configured to require Digest authentication for the /digest endpoint.

This means:

• the client authentication method was successfully manipulated
• but the server still enforced Digest validation

As a result, the authentication attempt failed

Using the intercepted credentials

Although the authentication failed, the Basic authentication step exposed credentials encoded in Base64.

These credentials can be decoded using tools such as CyberChef and potentially reused in a proper Digest authentication flow by generating a valid Digest response using:

• username
• password
• server nonce
• request metadata
• request metadata

username:password

Mitigation of this attack

This type of downgrade attack highlights weaknesses in authentication negotiation when HTTP is used without transport protection.

Mitigations include:

• enforcing HTTPS on all authenticated endpoints
• disabling Basic authentication in favor of stronger mechanisms
• enforcing strict authentication scheme validation on the server
• using HSTS to prevent protocol downgrade attacks

These measures prevent attackers from modifying authentication negotiation in transit.

Key lessons from the lab

This exercise highlighted several important concepts:

• Basic authentication is insecure without HTTPS
• Digest authentication improves security but still depends on protocol integrity
• MITM attacks often target negotiation phases rather than cryptography itself
• Burp Suite is not only a pentesting tool but also an excellent protocol analysis tool

Final thoughts

The experiment shows that the security of HTTP authentication relies on both the underlying mechanism and the robustness of its negotiation phase, which can become an attack surface when exposed in plaintext communication.