ToppyMicroServices

RFC 7616 Quiz

HTTP Digest Authentication

🇺🇸 🇯🇵
0 / 0

Primary reference

The questions review Digest as a challenge-response protocol while separating credential proof, replay policy, message coverage, proxy boundaries, and channel protection. Section numbers refer to RFC 7616.

Q1: How should a leaked Digest verifier be classified?

Multiple Choice · L3

A service stores H(username:realm:password) for each user. An attacker obtains that database but has not recovered the users' cleartext passwords.

**Explanation:** B is correct. Section 3.6 says a server can verify Authorization as long as H(A1) is available. Section 5.2 therefore requires the password file to be protected as if it contained unencrypted passwords: compromise gives immediate access to documents in that realm without first recovering the original password. A confuses not knowing the cleartext password with not possessing a usable verifier. C confuses the long-term credential equivalent with per-challenge nonce data. The realm is part of A1, so compromise does not automatically provide the corresponding verifier for every other realm, although weak passwords remain exposed to brute-force recovery.

Q2: Which Digest mode detects this request-body substitution?

Multiple Choice · L3

A client authenticates POST /transfer. An intermediary changes the entity body from one valid JSON instruction to another but leaves the method, request target, and Authorization header unchanged.

**Explanation:** C is correct. Section 3.4.3 defines A2 for auth-int as Method, request-uri, and H(entity-body). A body substitution therefore changes the expected response digest. With auth, A2 contains only Method and request-uri. A assigns body integrity to the wrong qop. B overstates Digest: Section 5.3 says that even auth-int protects only the message parts included in the calculation, and most header fields remain modifiable. Section 3.4.5 also specifies that the entity-body hash is computed before transfer encoding is applied and after it is removed.

Q3: What should the server conclude from a repeated nonce count?

Multiple Choice · L3

For the same username, server nonce, and client nonce, a server that tracks nonce counts has already accepted nc=00000003. It receives another correctly computed Authorization value with the same count.

**Explanation:** A is correct. Section 3.4 defines nc as the number of requests sent with a nonce and explains that a server can detect replay by maintaining its own count: seeing the same value twice marks a replay. The count and cnonce also participate in the response calculation when qop is used. B confuses credential proof with freshness policy. C ignores the stated replay-tracking state; nonce lifetime and nonce-count uniqueness are distinct checks. RFC 7616 does not make replay protection stateless merely by placing nc on the wire.

Q4: What is the correct client action for a stale nonce challenge?

Multiple Choice · L3

A server rejects an otherwise valid Digest response because its nonce is no longer valid. It returns a new challenge with stale=true and a fresh nonce.

**Explanation:** B is correct. Section 3.3 defines stale=true to signal rejection because the nonce was stale, allowing the client to retry with the new challenge without necessarily asking for a username and password again. A assigns a credential-failure meaning that the flag is specifically meant to distinguish. C reverses the mechanism: the old nonce is not extended, and the response must be recomputed using the new challenge. A server should set the flag to true only when the received nonce was invalid.

Q5: Which algorithm choice follows the Digest negotiation rules?

Multiple Choice · L3

A response offers separate Digest challenges in this order: SHA-256, then MD5. The client implements both, but local policy prohibits MD5.

**Explanation:** C is correct. Section 3.7 requires a server's multiple Digest challenges to use different algorithms and to appear in preference order. The client should use the first challenge it supports unless local policy dictates otherwise. Here the preferred challenge is supported and allowed. A invents last-one-wins behavior and selects an algorithm Section 3.2 marks not recommended. B is an optional conservative policy, not a conclusion required by RFC 7616; the allowed SHA-256 challenge remains usable under the stated policy. A hostile intermediary can attempt downgrade, which is another reason to protect the exchange with TLS.

Q6: How should the origin handle a Digest URI mismatch?

Multiple Choice · L3

After proxy rewriting, the request received by the origin targets /admin/delete, while the Digest Authorization uri is /status. The response digest is otherwise mathematically correct for the header value.

**Explanation:** A is correct. Section 3.4.6 requires the authenticating server to assure that the resource designated by the Authorization uri is the same as the resource in the Request-Line; on mismatch it should return 400 Bad Request. This input-side comparison prevents a proof for one target from authorizing another. B ignores a value that is part of A2 and the server's required resource check. C changes authenticated input without recomputing a response using the user's secret. The server must compare the effective meanings at the trust boundary, not canonicalize a mismatch into acceptance.

Q7: How should a proxy add its own Digest authentication?

Multiple Choice · L3

An intermediary wants to authenticate the client before forwarding a request. The origin already uses WWW-Authenticate and Authorization.

**Explanation:** B is correct. Sections 3.6 and 3.8 require proxies to be transparent to origin Digest fields. A proxy performing its own authentication uses a 407 response with Proxy-Authenticate, followed by the client's Proxy-Authorization request field. A corrupts the origin authentication exchange rather than adding a separate hop exchange. C conflates distinct protection spaces, challenges, and credentials; the proxy uses its own Digest parameters. A client can in principle authenticate to both proxy and origin, but not from the same response.

Q8: Which review best addresses replay and substitution for this A2A action?

Multiple Choice · L4

An automated agent sends state-changing POST requests with qop=auth. The server accepts a nonce for one hour and does not track nonce counts. A network intermediary can replay captured Authorization fields with a substituted body. No TLS is used.

**Explanation:** C is correct. Sections 5.4 and 5.5 call for special replay attention on POST and PUT. Limited-use or one-time nonces and nonce-count checking constrain reuse; auth-int binds the entity body. Section 5.1 recommends using Digest over a secure channel such as HTTPS, while Section 5.3 explains that Digest alone does not provide general confidentiality or integrity. A assigns body protection and replay state to auth and invents confidentiality. B addresses neither attack: Section 5.1 notes that algorithm agility does not rescue low-entropy password use, and a stronger digest does not create freshness state. Even with auth-int, most headers remain outside Digest protection, so the design must not treat it as complete message security.