用于防止重放攻击的 nonce 有必要使用密码学安全的随机数发生器生成吗？使用普通的随机数算法是否有安全问题？

有必要。

伪随机数生成器是保证密码学安全最基础的东西了。

普通的随机数，比如基于时间的，凡是有规律的都有可能被猜到。

@DefoliationM 实际的问题就是 nonce 被猜到是否会对安全性产生影响，因为 nonce 正常来说不是什么敏感信息

@drymonfidelia 仔细看看算法说明，绝大部分模式都需要 nonce 不可预测，伪随机数发生器并不满足。
简单来说，nonce 存在的目的就是引入额外的随机性避免一些弱点。你用伪随机数发生器，就存在随机序列被预测的可能，就留下了新的弱点。

更正一下，此处伪随机数发生器指一般的算法，不包括 CSPRNG 。

个人感觉感觉好多人把概念和用途都搞混了，说说我的浅见总结


什么是重放？
用你的原始请求数据原封不动地再发一次或者多次，别人只需要知道原始请求数据、再次发送即可，不需要猜测 nonce 不需要破解加密算法等


防止重放攻击的主要维度：
1. 幂等
比如金融或者其他涉及资金之类的业务，订单 ID 本身的幂等性是最基础的，已经实现了幂等的功能即使被重放也只是消耗算力
2. 时间
如果服务端对访问的时间有效期不做限制，那么任何一个请求数据被保存下来之后，任何时间都可以再次用这个数据进行请求；
所以，防范重访攻击的基础，是对请求时间有效性进行限制和校验：每个请求应该带上时间戳，服务端对时间戳与服务器时间做有效性校验，比如时差超过 30 秒认为请求不合法。


以上两点以外的其他防范，例如猜 nonce 算法、破解加密算法之类的来伪造请求内容，本身已经是生成新的请求了、跟重放的字面含义就已经不符了。
所以，严格来讲这些不应该归纳为重放，而是应该属于密码学范畴的攻防扩展了，例如：
1. crypto ，内容加密，对称非对称不同等级
2. sign ，不同 hash 算法验签
3. nonce ，加盐

就防止重放的目的来说，nonce 的生成算法只要防止碰撞即可。但是假如使用 nonce 作为返回值缓存的 key ，那么就需要采取措施防止将返回值泄露给无权限的用户。这种情况下就需要密码学安全的随机数发生器，最好也加上适当的权限验证。

实践上，nonce 除了用于防重放外，另一个常见作用是防止 CSRF 攻击（虽然 csrftoken 和 nonce 应该是有些区别的）。如果考虑反 CSRF 的作用，那么不可预测性就是必要属性，以保证攻击者不能通过猜解构造出下一次请求获得的 nonce 。

如果 nonce 的作用是单纯用于防止重放共计的，那其实顺序号就行了，程序处理起来还方便直观。
你看 EVM 上的很多合约，都是直接那一个 init 来作为 nonce ，不过这也和 EVM 数据存储结构有关系。

从安全角度来讲，只要生成逻辑是纯前端的，哪怕 Nonce+timestamp+signature 都无法防止重放攻击，攻击者也可能是恶意用户，不能只考虑攻击者在两个机器通信时做中间人的情况

@voidemoer 确实是这样，但是 nonce 好像没办法在后端生成。我的想法和 7 楼的比较接近，如果恶意用户逆向生成逻辑重新构造一个新的请求，那就不属于重放攻击了，因为是一个新的请求