接口防重放 是不是存粹的脱了裤子放屁？

> sync ，lock ，多线程等，工作中根本用不到

什么薪资、什么业务，怎么会连这些都不用……现在连 PHP 都考虑做单核并行化了，到底是什么水准很迷惑。

那不叫重试，那叫幂等性……给我看尴尬了。

@bigbigeggs #70

我看到你 70 楼的话了。怎么说呢，to C 业务 QPS 5~30k 起，并行化、分布式锁、链路熔断等，都会用到的。

譬如你要处理 50G 甚至更多的一份数据，流、ETL 或 Excel 等方式进来，你就需要并行化和锁来保证你的数据可靠性——同时提升效率。

只能说，多去大公司体验一下吧，QPS/数量级稍微高一些，很多问题都是需要你说的“用不到”的工具来更高效、可靠的解决。

看了半天，也没看懂防重放的要点。

脱裤子只会被爆菊

防重放在 99.9%的情况下都没有价值, 但遇到那 0.1%的情况轻些要花掉一个下午的时间梳理恢复数据, 重些年终奖就泡汤了

@bigbigeggs #69 客户端生成一对公私钥, 用私钥签名

@bigbigeggs 我做安全的不是专业开发本不想跟你扯这么多，既然你回我了，那就跟你友好探讨一下，首先我认为 token 应该是服务端生成告诉客户端的，客户端怎么会知道你是用什么参数生成的呢？客户端只需要请求的时候带上即可。即攻击者获得了 url ，例如 del?id=1&token=xxx ，攻击者不知道这个用户现在有效的 token ，这个请求到服务器经过校验是无效的啊，为什么不能防止重放呢？
其次，讨论的重点是重放，什么场景会有重放？重放有可能是想针对客户的攻击，例如我把嗅探到的其他用户转账的请求包重放；也可能是针对服务端的攻击，例如我把点赞重放来刷票，甚至也可能是用户觉得页面有点卡他又刷新了一下，你总不能说我在付款页面刷新一下你又扣了一遍款吧？重放不需要考虑你是怎么生成的，我只管把数据包重新发送就行，构造恶意的请求那是另一个范畴了。你可能把重放和 csrf 两个东西搞混了？
反而我认为你还被其他人误导了，中间人和重放不是完全划等号的，逻辑应该是存在中间人攻击的话会出现在重放这个问题，因为我可以获取到你的数据包，但重放也不只在中间人攻击中存在，所以 token 防止不了 mitm ，只能用来解决重放。你想想我都能获取到你往来的请求了，你下一个 token 我也知道是什么，我完全可以构造一个请求带上服务端给你返回的有效 token 。但是我重放你请求的包是没用的，使用 https 才是可以解决 mitm 的方案，之一，https 也并不完全安全，尤其是支持一些老版本的 tls 。
所以我才说你连 token 都没搞明白，因为我从你的描述中感觉你只知道 token 应该怎么生成，但你不知道怎么用，也不知道为什么要用

如果所有人时间都是准的那么完全没问题

@bigbigeggs
(1)业务幂等，这后端应该做的，没啥好讨论的
(2)保证请求参数合法，需要验证签名，确保参数是客户端发出的，客户端可以使用临时的密钥对，用私钥签名，请求的时候带上公钥，服务端验证签名。(用什么固定的 token 或者商量的盐值算 md5 什么的，都不太严谨，至于具体选择的算法不在此讨论
(3)防重放，这个防的是中间人攻击，一般做法请求参数里面有时间戳和 nonce
正常的项目，业务要关心的就是(1) 因为前人肯定搞定了(2)和(3)，这种通用的流程一次做好封装好就可以了的

openai 做防重放了吗？

> 放重放生成一个 token ，这个 token 人人都知道如何生成的，比如 timestap+参数 用 md5 进行加密，攻击者也可以完全模拟这个 token 的生成规则，来绕过服务端

？？？有点意思，你说的是知道 jwt token 吗？

还是你自己选一些参数经过组合再 md5 加密，带着这个结果提交？你认为这就是 token ？

你太年轻了。。。。你根本不知道大部分的攻击者都是半桶水，只要稍微做一下防重放，他的破解成本就会几何倍上升，你要知道很多脚本 boy 都是没有阅读源码的能力的，你作为一个开发者，肯定会觉得破解很简单，这是处于你了解并且知晓的情况下，实际上破解人处于黑盒状态，完全不知道为什么请求会被拦截，造成信息紊乱，大大提高了破解的难度，就好像我之前为了防止别人功能，即使把公钥放前端代码里面加密，依然能挡住 99.999%的攻击，剩下 0.0001%的人，是真大神，也没必要防了

CSRF Token 不是最基本的吗

@akira 你说的这个叫幂等性