摘要

  • RFC 7616 把 nc 定义为客户端声称使用当前服务器 nonce 发出的请求次数；服务器只有保留相应状态，才能凭重复计数识别重放。
  • 摘要计算把计数与凭据派生材料、nonce、HTTP 方法和请求 URI 等要素绑定，却没有把它变成全局请求 ID、授权决定或应用执行记录。
  • 会产生重要后果的系统还需要独立的操作标识和可查询结果。一次新的有效摘要认证可以证明重试者持有秘密，不能证明上一次尝试没有生效。

00000001 为什么容易令人过度放心

运维系统喜欢有顺序的数字。数字递增，似乎就有了历史；数字又进入认证计算，似乎这段历史还能被验证。HTTP Digest 的客户端会从 00000001 开始，在同一个服务器 nonce 下递增 nc，并把它与客户端 nonce 一起发送。服务器若保存自己的计数副本，看到同一个值再次出现，就能把它识别为重放。

这是一项真实的安全能力，但它有明确边界。

RFC 7616 的原话对象是“客户端使用本请求所带 nonce 已发送的请求数”，包括当前请求。定义没有说服务器已经受理了这些请求，也没有说它们到达同一个进程，更没有说应用状态按相同顺序发生变化。计数也不跨 nonce 保持唯一。服务器可以换 nonce，另一个客户端可以从头计数，另一个保护空间也可以使用完全不同的挑战。数字重新开始，说明认证上下文变了，不代表业务历史被清零。

因此，nc 能回答的是：在认证器为这次 nonce 交换保存的状态里，这个计数是否已经出现？它回答不了：随后到底形成了哪一笔可持久化交易？

计数必须有保存状态的对手方

只有服务器保存并比较自己的副本，客户端报来的计数才产生重放证据。脱离摘要计算的 nc 不是自证材料；日志里孤立的八位字符，也无法还原服务器采用了什么 nonce 生命周期和作用域。

这种策略本来就由实现决定。服务器生成对客户端不透明的 nonce，可以把它限制在某一客户端、资源、时间或使用次数内。一次性 nonce 能在使用后立即拒绝第二次使用，代价是服务器必须记住已用状态，而且管线化请求会受影响。较长寿命的 nonce 配合 nc，则在允许多个认证请求共享挑战的同时，保留相当一部分重放防护。

正是这种取舍，使计数无法升级成通用账本。两个合规服务可以设置不同的 nonce 寿命和状态保存范围；集群还必须决定重放状态是共享还是分片。故障转移、状态丢失或 nonce 轮换会改变认证层“记得什么”，却不说明应用数据库发生了什么。协议给出字段和比较规则，部署才承担状态保管责任。

摘要到底绑定了什么

启用 qop 后，响应值由密码派生材料、服务器 nonce、nc、客户端 nonce、qop，以及 A2 的哈希共同计算。qop=auth 时，A2 包含 HTTP 方法和请求 URI；qop=auth-int 时，还加入实体正文的哈希。由此可以在方案限定的保护空间内证明请求方掌握秘密，并让部分重放或篡改变得可检测。

边界有两层。第一，即使使用 auth-int，大多数 HTTP 头字段仍不在完整性范围内；RFC 7616 明确提醒，中间人可以改动这些字段。第二，认证不是应用授权。摘要正确，只能支持“请求方掌握配置的秘密”这一判断，不能代替“是否允许转账、删记录或轮换密钥”的业务策略。

Rifaat Shekh-Yusef 是这份 IETF 共识更新的主编和共同作者，而不是所有机制的发明者。RFC 2617 已经定义了 nonce 计数；RFC 7616 在继承它的同时加入 SHA-256、SHA-512/256、算法协商、用户名哈希，并强化安全说明。更强的摘要算法改善了规定的认证计算，但 RFC 同样直言：算法敏捷性救不了人类可记忆密码所面对的字典攻击。

认证响应仍不是业务回执

Digest 也有响应侧机制。Authentication-Info 可以带 rspauth，并重复它所对应请求的客户端 nonce 与 nc。这能支持相互认证：服务器证明自己掌握用户秘密；在 auth-int 下，还能提供有限的响应完整性。

它依然不是应用回执。回显的 nc 关联的是认证响应与请求，不会定义付款 ID、作业 ID、提交序号、回滚状态或可查询的业务结果。服务器可能先通过认证，再把请求交给队列；工作进程可能完成提交，而 HTTP 响应恰好丢失。客户端随后获得新挑战，发送一次完全有效的重试。两次摘要认证都正确，业务动作仍可能发生两次。

这不是 nonce 计数的缺陷，而是周边自动化把两类控制面混为一谈。凭据重放与业务效果重复有交集，却不是同一件事。

把一个绿灯拆成五份记录

重要操作至少应分开保存五个事实：认证是否通过；重放策略是否接受当前 nonce 上下文；应用授权是否允许动作；动作使用哪个持久化操作标识；最终提交了什么后置状态。有些系统还需要保存响应是否真正送达，因为操作完成与客户端看到响应也会分离。

应用级幂等键可以把多次重试归并到同一个意图；按该标识查询结果，则能让客户端在超时后先问“发生了什么”，而不是从一次新的认证成功里猜答案。RFC 7616 没有定义这两种能力，它们应由服务设计、持久化层和运营治理承担，不能靠重新解释 nc 获得。

严谨用法不是否定这个计数，而是让它只为自己观察过的事实作证：用它发现认证重放，保护赋予它意义的服务端状态，在合适场景使用 auth-int，并因 Digest 不提供机密性而配合 HTTPS。做到这里就应停止。认证计数不应被迫证明它从未看见的应用结果。

来源