HTTP Digest Access Authentication Schema

背景

本文内容大多基于网上其他参考文章及资料整理后所得，并非原创，目的是为了需要时方便查看。

介绍

HTTP Digest Access Authentication Schema，HTTP 摘要访问认证模式，是 HTTP 1.1 引入的替代 HTTP Basic Access Authentication Schema 的方案，为了解决 HTTP Basic Access Authentication Schema 中存在的安全问题：通过网络传输未加密的用户ID和密码。

HTTP Digest 同 HTTP Basic 一样，基于 challenge-response 认证机制实现身份认证方案，不同之处在于，HTTP Digest 不会直接发送明文密码，而是采用 checksum 检验方式对请求进行验证。

HTTP Digest Access Authentication 中的 challenge 使用一个 nonce 值，一个有效的 response 包含的 checksum 由 用户ID、密码、nonce、HTTP请求方法 和 HTTP请求URI 通过算法生成（默认 MD5），这样就永远不会以明文方式发送密码。

Challenge

服务器发送的 challenge：Digest digest-challenge，其中 Digest 指明服务器需要的访问认证方式，digest-challenge 格式如下：

realm | [domain] | nonce | [opaque] | [stale] | [algorithm] | [qop-options] | [auth-param]

其中 realm 和 nonce 这两个字段是必须的。字段说明：

• realm：一个标识受保护资源的字符串，指示用户应该使用哪个用户ID和密码进行认证。此字符串至少应该包含执行认证的主机名称，还可以另外指示哪些用户集合可能具有访问权限，如：registered_users@somehost。
• domain: 授权访问的URI列表，每项之间以空格符分隔。
• nonce：服务器每次返回 401 Unauthorized 时生成的唯一随机数，通常推荐使用 Base64 编码或十六进制数，实际依赖于服务器的具体实现。服务器向客户端发送 challenge 时会附带一个 nonce 随机数，客户端返回的 response 中摘要值计算会用到此 nonce 值。nonce 的存在增加了破解密码的难度，防范了 中间人 及 恶意服务器 等攻击类型。RFC 2617建议生成随机数的计算公式：nonce=Base64(timestamp MD5(timestamp:ETag:private-key))。
• opaque：服务器指定的一个数字字符串，客户端后续发送的对相同域（realm）的访问请求中，HTTP Headers 的 Authorization 应带有此值（保持不变），通常推荐使用 Base64 编码或十六进制数据。
• stale：一个标识，表明客户端的上一请求中使用了过期的 nonce 值。如果为 TRUE 则提示客户端使用新的加密 response 值重试请求。只有当服务器收到一个 nonce 过期的请求，但该 nonce 有一个有效的摘要（表明客户端知道正确的用户ID和密码）时，服务器才应该将 stale 设置为 TRUE。
• algorithm：一个字符串，指明生成摘要和校验和（checksum）的算法，如果没有设置则默认采用 MD5。
• qop：quality of protection，质量保护，包含 auth 和 auth-int 两种策略，默认 auth，auth-int 增加了报文完整性检测。
• auth-param：为未来扩展保留。

Response

客户端发送的 response：Digest digest-response，其中 Digest 指明客户端遵从的访问认证方式，digest-response 格式如下：

username | realm | nonce | digest-uri | response | [algorithm] | [cnonce] | [opaque] | [message-qop] | [nonce-count] | [auth-param]

字段说明：

• username：用于特定域（realm）认证的用户ID。
• digest-uri：请求的相对URI，因为代理在传输过程中可能修改请求，所以此处重复说明。
• response：摘要，是由32位十六进制数字组成的字符串，证明客户端知道密码。
• qop：同 challenge 中 qop 用途一致，必须是服务器发送的 challenge 中指明支持的 qop 之一，此值会影响摘要计算。
• cnonce：客户端随机数，使得双方都可以查验对方的身份，并对消息的完整性提供一些保护。
• nc：nonce 计数器，是一个十六进制的数值，表示同一 nonce 下客户端发送出请求的数量，在第一个 response 请求中 nc=00000001，目的是让服务器保持这个计数器的一个副本，以便检测重复的请求。
• auth-param：为未来扩展保留。

摘要计算

response 的值由三步计算而成，使用冒号作为分隔符合并多个数值：

1. 对用户ID、域（realm）及密码的合并值计算MD5哈希，结果称为 HA1（安全相关）。
   • 如果算法是 MD5，则 A1=<userid>:<realm>:<password>
   • 如果算法是 MD5-sess，则 A1=MD5(<user>:<realm>:<password>):<nonce>:<cnonce>

   HA1 = MD5(A1) = MD5(username:realm:password)
   

2. 对 HTTP 方法以及 URI 的摘要的合并值计算 MD5 哈希，如 GET 和 /dir/index.html，结果称为 HA2（报文相关）。A2 表示是与报文自身相关的信息，比如 URL，A2 加入摘要计算的主要目的是有助于防止反复。
   • 若 qop 为指定或指定为 auth，则 A2=<request-method>:<uri-directive-value>

   HA2 = MD5(A2) = MD5(method:digestURI)
   

   • 若 qop 指定为 auth-int，则 A2=<request-method>:<uri-directive-value>:MD5(<request-entity-body>)

   HA2 = MD5(A2) = MD5(method:digestURI:MD5(entityBody))
   

3. 对 HA1、nonce、nc、cnonce、qop 以及 HA2 的合并值计算 MD5 哈希，结果即为客户端提供的 response 值，计算规则：
   • 若 qop 没有指定，则 response = MD5(HA1:nonce:HA2)
   • 若 qop 指定为 auth 或 auth-int，则 response = MD5(HA1:nonce:nonceCount:clientNonce:qop:HA2)

流程

1. 客户端请求访问受保护资源；
2. 服务端接收到请求后，在请求头部（HTTP Request Headers）中未找到 Authorization，返回 401 Unauthorized，返回响应头（HTTP Response Headers）中带有 WWW-Authenticate：

   WWW-Authenticate: Digest realm="[e-mail]", qop="auth,auth-int", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="5ccc069c403ebaf9f0171e9517f40e41"
   

3. 客户端收到服务器响应后，使用 用户ID、密码、nonce、HTTP请求方法 和 HTTP请求URI，通过指定算法（如默认的 MD5）计算生成一个摘要，将此摘要与认证请求一起发送给服务器进行认证。客户端发送的认证请求中包含 Authorization 头信息，格式如下：

   Authorization: Digest username="Mufasa", realm="[e-mail]", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri="/dir/index.html", qop=auth, nc=00000001, cnonce="0a4f113b", response="6629fae49393a05397450978507c4ef1", opaque="5ccc069c403ebaf9f0171e9517f40e41"
   

   其中 response 的计算过程：

   HA1 = MD5("Mufasa:[e-mail]:Circle Of Life") = 939e7578ed9e3c518a452acee763bce9
   HA2 = MD5("GET:/dir/index.html") = 39aff3a2bab6126f332b942af96d3366
   response = MD5("939e7578ed9e3c518a452acee763bce9:dcd98b7102dd2f0e8b11d0f600bfb0c093:00000001:0a4f113b:auth:39aff3a2bab6126f332b942af96d3366") = 6629fae49393a05397450978507c4ef1
   

4. 服务器收到客户端的认证请求后，使用存储的密码和发送的参数计算摘要，如果与客户端发送的摘要匹配则认证成功。成功认证后，服务器可以返回 Authentication-Info 响应头，格式：

   Authentication-Info: nextnonce | [message-qop] | [response-auth] | [cnonce] | [nonce-count]
   

   字段说明：
   • nextnonce：如果服务器返回 nextnonce，则客户端下次请求的头信息中 Authorization 的 nonce 需要设置为此值，否则可能导致服务器要求重新认证。
   • message-qop：服务器应用与响应的 qop，auth 表示认证，auth-int 表示完整性认证保护，应该与对应的客户端请求中 qop 值一致。
   • response-auth：支持双向身份认证，即表明服务器知道用户的密码。
   • cnonce：同 response 中 cnonce。
   • nonce-count：同 response 中 nc。

注意：

• 后续客户端可以提交新请求，重复使用服务器密码随机数（nonce），服务器仅在每次响应 401 Unauthorized 时发送新的 nonce。
• 后续请求中，十六进制请求计数器（nc）必须比前一次要大，否则攻击者可以使用同样的认证信息重放已有的请求。
• 服务器应当记住最近生成的密码随机数（nonce），也可以为每一个密码随机数分配一个过期时间，如果客户端请求中携带的是过期的密码随机数，则服务器响应 401 Unauthorized，并在 digest-challenge 中添加 stale=TRUE，表明客户端应该使用新的密码随机数重发请求。

总结

HTTP Digest 相比于 HTTP Basic 的优势：

• 不发送明文密码；
• 使用随机数 nonce 防止重放攻击。

HTTP Digest 的缺陷：

• 如果摘要数据被攻击者截获，密码可能会被离线破解；
• 不提供消息完整性和机密性保护，最好配合 HTTPS 使用。

参考

[RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication](RFC 2617 - HTTP Authentication: Basic and Digest Access Authentication)