是否存在合理理由不应自行实现ID打乱算法用于应用安全防护

为什么不建议采用这套方案 #

• 所谓“攻击者需要猜对公式才能伪造校验值”的假设完全站不住脚。你举的示例本质是线性一次函数形式 y = a*x + b，这类运算根本不需要“猜”：拿你举的公式举例，y=57*x+8674，只要拿到自己账号ID=1对应的哈希值8731、ID=2对应的哈希值8788，两个值一减就能算出系数57，再倒算出常数项8674，10秒钟就能破解完整公式，之后可以批量伪造任意用户ID对应的合法哈希值，实现无成本越权。就算你换成更复杂的多项式运算，只要运算过程没有引入只有后端持有的、不随响应下发的独立秘密参数，都可以通过少量已知的输入输出对逆推参数，本质和“把用户ID乘2当校验值”没有区别。
• 方案完全没有抗重放、抗篡改的兜底能力。就算公式从来没被逆推出来，攻击者只要完整窃取了你存在localStorage里的（ID, 哈希）对，就可以直接复用这个值通过所有权限校验，后端根本识别不出这是窃取来的合法凭证。
• 你以为的性能优势实际上完全站不住脚。你觉得查数据库开销高？那是你对校验逻辑的实现路径想窄了：根本不需要每次请求查库的轻量校验方案已经非常成熟，比如带HMAC签名的令牌，后端只需要用本地保存的密钥对请求带来的凭证做一遍签名重算对比，整个过程是内存级运算，耗时是微秒级的，比你查数据库、甚至比你自己手写公式做运算的速度还要快，同时具备正经的抗伪造能力。

关于UUID作为用户标识的方案对比 #

• 首先要明确：UUID（或者其他形式的随机非连续主键）本身和权限校验是两个独立的问题。UUID的作用是避免攻击者通过遍历连续整数ID批量爬取用户公开信息，它本身解决不了“前端提交的用户ID是伪造的”这个核心风险——哪怕你用UUID当主键，如果没有配套的签名校验逻辑，攻击者只要通过抓包、泄露链接等渠道拿到其他用户的UUID，就可以直接提交这个UUID越权访问，和你用自增整数ID的风险没有本质区别。
• 合理的轻量权限校验方案根本不需要靠你手写自定义公式：用户首次登录验证通过后，后端生成一个带有用户ID、权限范围、过期时间的凭证，用仅后端持有的随机密钥做HMAC签名，把签名后的凭证返回给前端存在localStorage。后续每次访问受保护接口时，前端把凭证带上，后端只需要三步就能完成校验：
  • 用本地保存的密钥重新计算凭证内容的签名，和凭证里自带的签名对比，确认内容没有被篡改
  • 检查凭证是否在有效期内
  • 直接提取凭证里的用户ID执行后续业务逻辑
    整个过程不需要查数据库，性能远高于你原来的方案，同时因为密钥从来不会下发给前端，攻击者就算拿到上万组合法的历史凭证，也没法逆推出密钥、伪造其他用户的合法凭证。
• 对比下来你原来的自定义方案本质上是把“校验的秘密”寄托在公式的保密性上，但这种通过算法保密获得的安全性是完全靠不住的——算法本身是可以被观察、被逆推的，只有把秘密寄托在从来不会暴露给外部的随机密钥上，安全性才是成立的。

内容的提问来源于stack exchange，提问作者crevulus