是否允许客户端在摘要 HTTP 身份验证中选择挑战（随机数）？答案

【问题标题】：Is the client allowed to choose challenge (nonce) in Digest HTTP authentication?是否允许客户端在摘要 HTTP 身份验证中选择挑战（随机数）？
【发布时间】：2011-02-09 08:45:27
【问题描述】：

摘要式身份验证看起来像是一种挑战-响应机制：客户端和服务器都将随机字符串与密码（MD5 或其他内容）混合在一起，并且只有这种混合的结果通过网络发送。

通常挑战（“nonce”）由服务器选择并发送给客户端。摘要式身份验证中的Wikipedia article 列出了一个示例“会话” - 挑战（“nonce”）由那里的服务器选择。我在我的机器上使用 IIS 进行了相同的测试 - 再次，挑战是由 IIS 生成的。

但在like this one 的某些帖子中，挑战是由客户端生成的 - 客户端只是生成一个随机字符串并发送一个请求，其中包含挑战以及密码和挑战的乘积。

后者是否被允许并被广泛接受？是否允许客户端选择挑战（“nonce”）？

【问题讨论】：

标签： security http digest digest-authentication

【解决方案1】：

在 HTTP 摘要认证中，服务器总是生成随机数。

但是，HTTP 身份验证是可扩展的，应用程序可以实现其他身份验证方法（基本和摘要之外）。在您链接到的示例中，客户端使用WSSE 进行身份验证，这是一种用于（主要基于 SOAP）Web 服务的身份验证形式。在 WSSE 中，客户端生成随机数。

【讨论】：

【解决方案2】：

Digest Access Authentication scheme 只是一种单向身份验证，客户端向服务器验证自己，但不反之亦然。只有服务器发出质询，客户端需要正确响应才能进行身份验证。所以只有服务器知道客户端是否真实，而客户端不知道服务器是否真实。

现在链接代码的作用正好相反：客户端向服务器发出质询以对其进行身份验证。所以客户端知道服务器是否真实。

最好使用mutual authentication。

【讨论】：

在链接的示例中，客户端根本不会向服务器发出质询，它是在抢占来自服务器的质询。
@Phil：你确定吗？这意味着客户端可以真的选择任何随机数来验证自己。那么服务器端的真实性验证是怎样的呢？好吧，幸运的是，通信是通过 HTTPS 进行的。
阅读我在回答中链接到的 WSSE 文章。客户端传输其密码散列和随机数，服务器使用这些散列生成自己的密码散列，以与客户端发送的散列进行比较。它允许对摘要进行小幅优化：无需额外往返即可从服务器获取随机数。
@Gumbo：哪一方发出随机数并不重要。随机数被发送给另一方，双方构建随机数和秘密的产品，客户端将产品发送到服务器，服务器验证它是否与自己构建的产品匹配。
@sharptooth：这确实很重要。如果在你可以进行重放攻击时没有真正使用 nonce（实际上，这是 nonce 的唯一目的）。所以服务器必须记住已经使用过的随机数。在这种情况下，如果服务器只需要记住它实际发出的那些随机数会更好。