NIST为各种算法的密钥和散列长度提供了很好的指导。但我没有看到任何关于随机或伪随机随机数（使用一次的数字）长度的具体内容。
如果对各种用途有一个好的答案，我很乐意看到。但为了具体化，我将使用常见的“通过电子邮件重置密码”情况，在这种情况下，服务器会生成一个带有伪随机路径组件的 URL。它似乎有点类似于 HTTP Digest Authentication，其中RFC 中的示例似乎有 136 位 (dcd98b7102dd2f0e8b11d0f600bfb0c093)。
我注意到许多人似乎使用第 4 版 UUID（提供 122 个伪随机位）或这个，正如GUID 对一次性令牌安全吗？，尽管用户必须小心使用以前更可预测的 UUID 版本，以及对 Windows 随机数生成器的讨厌的持续本地攻击，这些攻击大多在 2008 年得到修补。
但是忽略在 UUID 版本和实现中纠结的风险，应该在 URL 中包含多少伪随机位？
如果 64 位是加密质量的随机性，则 64 位随机数对于大多数实际用途可能绰绰有余。
为什么 64 位就足够了？ 让我列出你可以用来回答这个问题的推理。我假设这是一个一次性的限时 URL；使用一次后，它就不再有效，过了一会儿（比如3天），它就过期了，不再有效。由于 nonce 只对服务器有意义，攻击者可以尝试猜测的唯一方法是将 64 位猜测发送到服务器并查看服务器如何响应。在随机数到期之前，攻击者可以尝试多少次猜测？假设攻击者每秒可以发出 1000 个 HTTP 请求（这是一个非常强大的攻击者）；那么攻击者可以在 3 天内进行大约 1000*3600*24*3 = 2 28次猜测。每个猜测都有 1/2 64正确的机会。因此，攻击者最多有 1/2 36的机会破坏该计划。对于大多数设置来说，这应该足够安全。
首先，估计您的系统将获得的最大使用量（生成随机 nonce 的次数）。接下来，确定可接受的安全级别，即随机数与旧随机数重复的可能性有多大。计算使用次数（以位为单位），将其加倍并添加所需的不可能性（以位为单位），您就有了随机数长度。
带有随机 IV 的 AES-GCM 示例。对于某个密钥，随机 IV 允许的调用次数为 2 32。IV 被重用的概率必须小于 2 -32。所需的随机数长度为 32 × 2 + 32 == 96 位。
如果假设您希望能够生成 2 96 个数据包，每个数据包都有一个随机 nonce，并且希望重复 nonce 的概率小于 2 -32，那么您需要一个 96 × 2 + 32 == 224 位长。
将此与上述 64 位的答案进行比较...如果您的系统使用次数超过 2 16 (65536)，则在此期间出现重复随机数的概率超过 2 -32（超过 40 亿分之一） ，小规模）。根据您的安全要求，这可能是完全可以接受的，也可能不是。
作为一个适合所有答案的答案 - 提到的随机 UUID 是一个非常好的解决方案。
请注意，这些值是近似值，更准确的计算要复杂得多。
对于密码重置，您将使用盐而不是随机数作为令牌。也就是说，您只需要生成一个 salt，将其存储一段时间与用户帐户相关联，然后等待用户单击其中包含该 salt 的链接。您无需跟踪这些令牌以确保它们不会被多次使用。使用令牌后，只需将其删除。
您应该使用至少 128 位，由强加密伪随机数生成器生成。您不需要 UUID 格式 - 您只需要足够长的加密随机字符串。
对于 URL，您可以使用 base64url 编码或十六进制编码。base64url 编码会更短，但会区分大小写。base64url 编码与 base64 编码略有不同，因为不需要终止符='s 并且+and/被替换为-and _，哪些字符不需要为 url 专门编码。