A team proposes HTTP Digest Authentication for a new internal API, arguing it avoids sending passwords over the wire. How would you evaluate that proposal against Basic Authentication over TLS or bearer tokens?

## Start by naming the threat Digest actually addresses Digest Authentication solves exactly one problem: an eavesdropper on an unencrypted connection should not learn the user's password. It was designed in the 1990s when TLS was expensive and often absent. Framing the evaluation this way immediately clarifies the decision — if the link is encrypted, the scheme's entire benefit has already been delivered by something else, and only its costs remain. ## What Digest does not protect Even when it works perfectly, Digest leaves the request body, the response body, cookies and every other header in cleartext. With the near-universal `qop=auth`, the body is not even integrity-protected, so an active attacker can change what a POST does while its credential stays valid. And because nothing signs the `WWW-Authenticate` challenge, a man in the middle can replace a Digest challenge with a Basic one and harvest the password directly — a downgrade the protocol cannot detect. A scheme that fails against an active attacker but is only needed when the channel is unprotected is answering a question no one asks any more. ## The storage argument is the decisive one To verify a digest the server must possess `H(A1) = H(username:realm:password)`. It cannot store a salted, slow hash like bcrypt or Argon2, because those cannot be converted into H(A1). So adopting Digest means deliberately regressing password storage to a fast unsalted digest that is *password-equivalent for the realm*: an attacker with the table authenticates directly, no cracking step at all. Basic over TLS, for all its crudeness, hands the server the cleartext password once per request, which is precisely what lets it verify against a modern password hash. On the single axis of credential-database compromise — the most common real breach — Basic over TLS is *stronger* than Digest. ## Operational friction Nonces must be validated across a fleet, so either the servers share nonce state or the nonce is a MAC over a server secret that must be distributed and rotated. Real replay protection needs per-nonce `nc` high-water tracking, which is shared mutable state that most implementations quietly skip. The `uri` parameter is inside the digest, so any gateway that rewrites paths breaks authentication. Client support is thin outside browsers, and browser Digest means a native credential dialog with no branding, no password manager reliability and no logout. Library support in modern HTTP clients is inconsistent and rarely exercised. ## What the alternatives give you that Digest structurally cannot Bearer tokens carried over TLS bring **expiry** (a stolen token dies on its own), **scopes** (a token that can read cannot delete), **revocation** (kill one session without a password reset), **delegation** (a service acts for a user without ever seeing the password), **audience binding**, **MFA and step-up** (the login flow is yours to design), and a **service-to-service story** via client credentials or mTLS. Digest has none of these; it authenticates a password on every single request, forever, with no notion of a session that can be ended. ## How to answer as a decision, not a lecture The useful response is a recommendation with a migration shape: terminate TLS everywhere and treat that as non-negotiable; issue short-lived access tokens from a central identity provider with refresh handled out of band; use mTLS or workload identity between services; and if a genuine legacy constraint forces HTTP-level credentials in the short term, use Basic over TLS with bcrypt or Argon2 storage and a plan to retire it. Reserve Digest for the one case where it still appears — embedded devices, IP cameras, printers, some SIP equipment — where no TLS stack exists and the firmware cannot be changed, and then treat those devices as untrusted and segment them. ## The nuance worth conceding One honest point in Digest's favour: with Basic, the origin server sees the password on every request, so a compromised or over-privileged server — or an over-eager access log — leaks it. Digest never reveals the password to the server. That is real, but it is dominated by tokens, which also never expose a password to the resource server and additionally expire, scope and revoke. So the concession strengthens the case for tokens rather than for Digest.