攻击者的目标是猜测密码。通过观察身份验证消息，攻击者已经学会了足够的知识来在家中“尝试”密码（即“离线字典攻击”），但这并不是 RFC 2617 所讨论的内容。相反，它专注于冒充服务器的攻击者的想法，从而将其选择的“服务器”随机数提供给客户端。客户端通过将服务器随机数、客户端随机数和密码一起散列来响应这样的随机数（我自愿跳过此处的详细信息）。然后，攻击者可能会尝试利用散列函数的一些内部弱点，从客户端发送的内容中重新计算密码。RFC 2617 试图说的是，省略客户端 nonce 只会让攻击者的事情变得更容易（至少可以证明不是更难，如果散列函数不稳定，可能有助于保护客户端；客户 nonce 肯定不会造成额外的伤害。

现在，当在 RFC 2617 中描述的摘要访问身份验证中使用时，目前还没有已知 MD5 的可利用弱点。尽管 MD5 在抗碰撞方面表现出相当大的脆弱性，这是一个好的散列函数应该具有的另一个独特的安全属性（而 MD5 没有）。因此，客户端 nonce 提供的保护只是假设性的。但是，正如我所说，它也没有害处。

RFC 的那部分提出了一些可疑的声明，并且写得不是很好。这就是我认为它应该说的。

1. 如果您允许攻击者控制哈希函数的部分输入，那么您必须考虑这是否会启用对哈希函数的选择明文攻击。如果客户端没有提供任何随机数，那么人们可能会担心恶意服务器可能会恶意选择其服务器随机数，以尝试对散列函数进行某种选择明文攻击。

   幸运的是，当前的哈希函数被设计成可以抵御选择明文攻击，所以这种担心在实践中并不是真正的风险。

   另一方面，如果您想非常谨慎，我想您可以尝试通过包含客户端选择的随机数来减少此类攻击的机会。这样，即使服务器是恶意的，仍然可以保证散列函数的输入是随机的，攻击者无法控制，攻击者也无法预测。目前尚不清楚这是否真的提供了任何好处（这可能是不必要的），但它不会受到伤害。

   有关详细信息，请参阅@Thomas 的答案。

2. 让两个端点贡献自己的随机 nonce 通常是一种很好的工程实践。例如，在某些情况下，这有助于防止某个端点是恶意的某些类型的重放攻击。

   我不知道忽略客户端 nonce 是否真的会启用对 RFC2617 的某种巧妙的重放攻击，但为什么要冒险呢？如果有一个简单的修改我可以排除一整类可能的攻击，那么这个修改看起来很有吸引力。任何使我不必认真考虑微妙攻击（并且可能忽略一个，这是灾难性的）的事情感觉都是一件好事。

3. 在 RFC2617 的情况下，当服务器是恶意的时，包括客户端随机数可以防止预计算攻击（例如，时间/空间权衡攻击、“雨箱表”等）。有关更多详细信息，请参阅@ixe013 的回答和我的评论。

是的，它仍然是 SHA1 的问题。它与实际的散列算法无关，除了攻击者需要更多的空间来存储查找表，并且可能需要更多的时间来计算它们。

摘要是用户名、密码、给定的 nonce 值、HTTP 方法和请求的 URI (RFC2617) 的哈希值。攻击者知道所有这些（但密码除外），因此可以提前准备一个查找表。这样的表不能预先计算客户端添加它自己的随机数（cnonce），攻击者事先不知道。