您想在以下情况下使用随机数：

• 您非常关心传输不会被提交两次

和/或

• 您有理由担心授权用户以外的其他人可能会发生重新传输，并且后果会很糟糕

金钱易手的交易是一个很好的示例用例——我非常关心我不会在没有知情同意的情况下两次购买相同的产品。此外 - 任何授权情况 - 当客户端将凭证传输到服务器时以及服务器对凭证验证服务执行身份验证检查时。在任何一种情况下，如果第三方听到了传输，则可以在以后模仿合法来源重复传输。

一般原则是，如果我是相关方，我可以给你一个适当独特的、不可预测的数据，让你把它连同你所说的那个人的证据一起传回给我——你的身份证明并且这些适当唯一的数据应该以这样一种方式融合在一起，即如果没有唯一信息和您的凭据，听众就无法复制它们。

Web 表单是一个很好的背景，因为有很多好的案例。但这不是实现基本概念的唯一选择——例如 OCSP 在证书查找中使用随机数（完全非网络——都在 ASN.1 中）。我不想增加混淆，但我想强调的是，nonce 是一个安全概念，而不是给定技术或协议所独有的东西。

一一回答问题：

1.发送给客户的“挑战”是什么？

适当随机的东西。像往常一样，完美的随机性被认为是不可能的——但它是足够独特的，以至于它不会以可预测的方式或频繁地重复。因此，作为攻击者，我无法建立可用传输的库存并重用以前使用的随机数。

2.服务器向客户端发送挑战，如何？在会话中？表单中的隐藏输入？网址？

在 UI 意义上，您希望将其从用户那里抽象出来，因为他们在逐字传输过程中没有任何作用。您打包它的方式与您要解决的问题完全相关。例如：

• 在 OSCP 请求/响应中，nonce 是 ASN.1 中的一个字段 - 它具有协议中指定的对象标识符和一个值。我不记得了，但它可能仅限于整数。

• 如果您尝试将 nonce 附加到 web 表单，则表单输入参数中的隐藏值是一个好主意。通常将其粘贴在 URL 中是个坏主意，因为 URL 适合导航和书签，而且这不是可重复的数据 - 下次我用这个 nonce 提交表单时，我应该被拒绝，所以如果我为带有随机数的 URL，我应该非常沮丧。

• 在 XML 事务中，我相信在 XMLDSIG 模式中包含 nonce 是一种选择——它是它自己的一个元素——这通常用于 SOAP Web 服务中。

3.客户端如何使用哈希密码响应？是客户端=php？

这又回到了 nonce 是一个概念而不是实现这一点。许多 API 提供一个随机数作为请求启动的参数 - 通常是一个布尔值 - TRUE/FALSE 根本就提供一个随机数。

在任何情况下，无论客户端如何响应，都需要在 nonce 和证明客户端身份的私有凭证之间建立连接。散列随机数和密码可能是一种方法 - 但这不是我使用过的方法。但是我的背景很大程度上与 PKI 相关。如果您使用非对称密钥，那么典型的做法是将随机数作为包的一部分进行签名 - 因此响应将是对交易很重要的信息集合（例如我的购物车订单），关于我是谁的信息am（例如，我的数字证书或用户名）和我的 nonce。我如何打包这是我的应用程序的设计细节。

4.这种方法提供什么类型的安全性？

独特性。

它确保了这种交换是“实时”发生的——响应不是一个预设的响应，它可以很容易地由恶意实体给出，就像由预先生成响应的服务器一样，它确保我不能两次发送相同的事务并且有它两次都有效（重放攻击）。

有一个成本——计算和处理的成本。在高负载情况下，每次传输都要求重新生成和加密绑定可能会变得昂贵。不是非常昂贵，但对于非常高的负载，即使是一点点也很重要。它还强制请求者保持持久性——请求者必须制作一个随机数，发送它，记住它，并在提供返回响应时进行比较。如果没有请求/响应随机数比较，那么首先提供随机数就没有任何价值。这意味着那里也有内存和计算成本。此外，如果您出于特殊目的自定义构建事务，则会增加开发时间/成本。显然这是一次性成本——但它仍然是需要做的工作。

1. 一个随机值。

2. 通常作为表单中的隐藏值。

3. 通常，我们不想要@Thomas 描述的协议。我们想要的是让您使用 SSL 并在服务器端散列密码。

4. 这可以防止重放和盲提交 (CSRF) 攻击。

如果你曾经在网上买过东西，并在最后看到一个页面，上面写着“不要刷新或重新提交这个页面，否则你会被收取两次费用”，那么你已经找到了应该使用 nonce 的人。

通过创建一个（足够大的）随机值附加到应该提交的表单上，您可以确保表单只使用一次。此外，CSRF 被阻止，因为您必须首先访问表单页面才能生成接收有效的随机数。

加密的登录表单可能不需要随机数，但随机数可以有效地对密码进行唯一散列，以防止通过不安全的通道重播。