请教接口 signature 的问题

参数里加个类似时间戳的随机数，稍微增加点难度

上公私钥

楼主知道 36 的 100 次方是多大的数吗？

阀值：阈值

@leo108 首先，我们用的 32 位 md5，其次，类似彩虹字典，大数据暴力破解这些，你知道吗？

简单的办法，可以先对其中的某个参数先进行一次 md5，再拼接，再整体 md5。

@GGGG430 这里的 100 指的是被签名参数的长度，100 已经是非常保守的数字的

@silverbooker 多层 md5 我在以前的一个 webshell 中见过，意义不大，黑客无非多破解一层即可

md5(md5(key+md5(key)))

@leo108 signature 的长度无非就是付出与收获的正比，当某个接口的数据足够重要，再长的长度也就没有了意义

彩虹表都是针对于常见密码制作的，urlencode 后请求参数这些光&符号和=号就已经不符合一堆彩虹表的制作习惯了。

一般 md5 前会约定秘钥(salt) 才是决定接口是否安全的因素之一，一般的 salt 可能是约定好的字符串也肯能是请求头中的某个参数
客户端和服务端会约定参数中加入时间戳，超过一定时间窗口的请求会被服务端丢弃的。
而且有些接口会让你添加一些随机字符串防止相同参数相同请求生成的签名重复

接口使用签名保护接口核心就是需要保护秘钥不泄露，其次才是考虑如请求重放服务端是否需要考虑幂等性之类的至于彩虹表压根不会在考虑范围

@GGGG430 建议先学一下初中数学，基本的 log 运算什么的，然后搜索一下『宇宙有多少原子』

@leo108 求你别再这里说了, 很讨厌你这种杠精, 题主是来寻求帮助的, 不是来听你杠的

什么价值的服务值得去破解 md5 ？

参数到一定程度的时候，预先算出的彩虹表请问用什么来装？全球的硬盘都不够用，谁会无聊存那么多彩虹表，你怕是对彩虹表有什么误解吧

@summerwar 需要考虑实际情况, 毕竟真实情况下客户端也不会使用超过一定长度的密钥的

恍惚间以为自己活在上个世纪。

2004 年开始，MD5 已经不能用于任何需要安全性的应用密码方案。

另外楼主语焉不详，请详细描述你需要的安全措施具有的语法、正确性和安全性，然后搜索业界成熟的解决方案。

加 timestamp，用 sha256

const signature = crypto.createHmac('sha256', signingKey).update(timestamp + parameters).digest('hex')

@geelaw
@MiffyLiye
实际场景就是前后端接口的安全问题上, 是否能有一个前后端均能处理的算法, 且具有足够安全性(难以破解)的途径

@GGGG430 别人给你正常的建议你怎么一条都没回呢？加个时间戳就解决了大部分问题，复杂一点上公私钥。还有，没有人会用彩虹表去破解你的签名的

@aWangami 没回复是觉得不够安全, 另外这个接口使用很广, 已经有爬虫破解过多次 signature 了, 目前在处理服务层反爬虫+业务接口层校验参数

反爬虫和签名的安全性真的没关系
你需要的是限制客户端账号的访问频率、增加识别是否为人类的验证码、数据中隐藏陷阱并吐出脏数据

前端程序都是公开的，signingKey 你准备怎么藏起来

@lshero 服务层正在做这件事

@MiffyLiye 业务层中虽然前端是暴露的，但我们也想提升相应的安全性，不然所有业务层接口都接入服务层反爬虫，代价过大

楼主，加 slat 了解一下。

多层散列没有任何帮助，甚至有可能降低散列效果。

另外高安全性的东西肯定不能这么用，但是一般的接口，这个彩虹字典得多打才能破解得了啊，就算能行成本也太高了吧

哦我搞错了彩虹表的作用，楼上说得对加盐可破

@luckyrayyy 也许对方是通过反编译客户端来获取到的密钥 key, 被破解几次后不再相信这个了

@loading 没有理解好, 你能说一下具体吗, 和上面说的约定一个 key 来加密区别是什么

大兄弟，反爬虫和 API 安全 无关

反爬虫是行为分析问题

@chinvo 两手并抓嘛

“爬虫破解过多次 signature ” 说明是密钥外泄而不是被破解

应该像#22 那样限制每个客户端访问频率，签名是保护接口参数不被篡改，而不是防止被第三方调用的

@GGGG430 爬虫破解的时候十之八九不是用的彩虹表，而是分析逆向你们前端代码得到的。看起来反爬虫才是你要解决的问题，而不是 signature 是否安全。signature 能解决大部分的问题，至于爬虫，你们可以通过更复杂的校验方式去识和处理，比如限制 ip，限制 cookie、限制 user-agent、前端代码混淆等方式组合处理。

闲的蛋疼吗这不是，我为什么要花那么大代价搞字典去破解你的签名，而不是反编译你的客户端？你自己把路走窄了，妄图通过签名来提高接口的“安全性”，这路子不太对吧。最关键的还是因为客户端跑在客户手里，你如果想反爬，应该走#22 说的路子才对

@GGGG430 你可以整体 md5 套 上部分参数 md5 再设计一些 shuffle 规则再加上 shuffle 规则动态更新，用彩虹表肯定是破不了的。不过做爬虫的人可是不会用彩虹表来破签名的，都是直接逆向反编译静态分析或者下钩子。

如果是 App 的话，可以看看一些商业壳。
如果不是的话，可以了解一下瑞数动态加密。

@silverbooker 嗯, 增加加密规则复杂度感觉在反编译 /逆向破解面前用处不大, 对方既然可以看到 key, 那也可以看到客户端的加密规则, 目前处在鸡肋的阶段中...

这种东西抛开业务空谈没有意义，加密强度取决与业务重要性，你就传个头像地址疯狂加密有啥用？所以没业务场景在这空谈没意义

@GGGG430 我上面只是说了 楼主对彩虹表没有理解，不知道是啥概念，别的没讨论

@lshero 可惜这里至少 90%的人对这些基本的概念都完全不了解。。。

题主是没看懂 3 楼的话吧

@danmu17 业务上吃几次亏就了解了