RFC 7616 added SHA-256 to HTTP Digest Authentication alongside the legacy MD5 algorithm. How does a server offer both without breaking old clients, and what makes migrating an existing user base genuinely painful?
answer
- multiple challenges, strongest first
- client picks first algorithm it knows
- H(A1) is per-algorithm, not convertible
- realm is inside A1 too — renaming breaks it
- userhash + charset=UTF-8 also new in 7616
basics
~20 sThe server sends two WWW-Authenticate challenges, strongest first (SHA-256, then MD5), and the client picks the best it supports. The pain is storage: the server keeps H(username:realm:password) per algorithm, and it cannot compute the SHA-256 one from the MD5 one — so it must capture each user's password again, typically via a reset.
solid answer
~50 sRFC 7616 lets a server send **multiple `WWW-Authenticate: Digest` challenges in one 401**, ordered most-preferred first, each with a different `algorithm` (`SHA-512-256`, `SHA-256`, `MD5`). A conforming client selects the strongest algorithm it understands and ignores the rest; an old client sees the MD5 challenge and keeps working. The hard part is server-side state. Verification needs `H(A1) = H(username:realm:password)` for the *specific* hash function in use. An MD5 H(A1) is a one-way digest — you cannot derive the SHA-256 one from it. So a migration means storing a second column and populating it only when you next see the actual password, which with Digest you never do. In practice you force a password reset or a one-time enrolment flow over TLS. RFC 7616 also adds `charset=UTF-8` and the `userhash` parameter so the username can be sent hashed rather than in the clear.
code
http · 5 linesHTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest realm="[email protected]", qop="auth",
algorithm=SHA-256, nonce="7ypf/xlj9XXwfDPEoM4URrv", userhash=true
WWW-Authenticate: Digest realm="[email protected]", qop="auth",
algorithm=MD5, nonce="7ypf/xlj9XXwfDPEoM4URrv", userhash=falsego deeper
Know that the algorithm parameter selects the hash and that MD5 is legacy while SHA-256 is preferred.
Explain multi-challenge negotiation and why stored H(A1) cannot be converted between algorithms.
Add the operational migration plan — dual columns, forced reset or enrolment flow, a deadline for dropping MD5 — and the downgrade exposure while both are offered.
Argue whether the migration is worth funding at all versus retiring Digest for TLS plus tokens, and account for the embedded fleet that cannot be upgraded.
## What RFC 7616 changed RFC 2617 hardwired MD5. **RFC 7616** (2015) generalised the `algorithm` parameter and registered `SHA-256`, `SHA-512-256`, and their `-sess` variants, keeping `MD5` registered only for backward compatibility. It also added `charset=UTF-8` so non-ASCII passwords hash consistently, and `userhash`, which lets a client send `username*` as a hash of `username:realm` so the account name is not exposed in the clear on the wire. ## Negotiating two algorithms at once HTTP allows several authentication challenges in one response — either as repeated `WWW-Authenticate` header fields or comma-separated in one. RFC 7616 says the server lists them **in order of preference, strongest first**, and the client picks the first one whose algorithm it supports. So a 401 carrying a SHA-256 challenge followed by an MD5 challenge serves both generations: modern clients answer with SHA-256, legacy clients skip past what they do not recognise and answer with MD5. The obvious weakness: an active attacker who can modify the response strips the SHA-256 challenge and leaves MD5, and there is no integrity protection on the challenge to detect it. Dual challenges are a compatibility mechanism, not a security one. Once every client has moved, the MD5 challenge must be removed — otherwise the deployment is only as strong as its weakest offered algorithm. ## Why the storage migration is the real cost A Digest server does not store passwords in a modern password hash; it stores `H(A1) = H(username:realm:password)` because that value is a required input to verification. Three consequences follow: 1. **H(A1) is algorithm-specific.** The MD5 H(A1) and the SHA-256 H(A1) are independent one-way digests of the same input. There is no function that maps one to the other. Turning on SHA-256 for existing accounts requires the cleartext password again. 2. **Digest never gives the server the cleartext.** Unlike a form login, a successful Digest authentication proves knowledge of the password without revealing it, so you cannot opportunistically backfill the new column at next sign-in — the very property the scheme was built for blocks the migration. Realistic options are a forced password reset, a one-time enrolment flow over TLS, or running both algorithms indefinitely. 3. **H(A1) is password-equivalent.** Whatever the hash function, a leaked table lets an attacker authenticate to that realm directly, with no cracking required, and there is no salt or work factor to slow offline attacks against reused passwords. Moving MD5 → SHA-256 removes a broken hash from the picture but does not fix this, because the design forbids bcrypt or Argon2 outright. ## Also note the realm dependency Because the realm string is inside A1, changing the realm invalidates every stored H(A1) exactly as changing the algorithm does. Renaming a realm is therefore a second, equally painful migration — a detail that surprises teams doing hostname or branding changes. ## The honest conclusion RFC 7616 fixed the cryptographic embarrassment of mandatory MD5, but it could not fix the structural problems: no confidentiality without TLS, no compatibility with modern password storage, no defence against an active downgrade, and a migration path that requires touching every user's password. Those are the reasons the modernisation did not revive adoption — by 2015 the answer was already TLS plus tokens, and the practical audience for SHA-256 Digest was existing embedded and SIP deployments hardening what they already ran.
- If a server keeps offering the MD5 challenge alongside SHA-256, what is the security value of having added SHA-256?Close to none against an active attacker. Because nothing protects the integrity of the 401 response, a man in the middle can delete the SHA-256 challenge and leave only MD5, and the client will comply. Offering both is a compatibility bridge with a deadline; the security benefit only materialises once the weaker challenge is removed.
- What does the `userhash` parameter do?When the server advertises `userhash=true`, the client may send `username*` as a hash of `username:realm` instead of the plaintext account name, so passive observers do not learn who is logging in. The server must be able to look up the account by that hash, which means precomputing it per user and per realm.
saying these in an interview costs you the question
- Claiming the server can recompute the SHA-256 H(A1) from the stored MD5 one
- Thinking dual challenges prevent downgrade attacks
- Assuming SHA-256 makes Digest safe without TLS
- Saying you can store bcrypt now that SHA-256 is supported
- Forgetting that the realm string is baked into A1, so renaming a realm invalidates stored credentials