这是一个创建于 1964 天前的主题，其中的信息可能已经有所发展或是发生改变。
参考了市面上很多接口 signature 参数生成方式, 基本都是选择某几个参数拼接上实现约定好的一个 key, 最后 md5 生成 signature.
这种方式我觉得在大数据(彩虹字典之类)下, 对方事先将所有字符串(长度低于一个阀值, 毕竟我们接口这里也不可能用很长的字符串)都生成一遍 md5,很容易破解.
各位大佬有觉得比较好的办法吗
第 1 条附言 · 2019-07-16 13:09:24 +08:00
此贴总结: 如 #32 楼所言, 签名是保护接口参数不被篡改, 我对签名给予过多的期望了
 |
1
CoX 2019-07-16 11:32:13 +08:00
参数里加个类似时间戳的随机数，稍微增加点难度
|
 |
2
wangsongyan 2019-07-16 11:36:40 +08:00 via iPhone
上公私钥
|
 |
3
leo108 2019-07-16 11:40:22 +08:00
楼主知道 36 的 100 次方是多大的数吗？
|
 |
4
hellomimi 2019-07-16 11:41:58 +08:00  1
阀值：阈值
|
 |
5
GGGG430 OP @leo108 首先，我们用的 32 位 md5，其次，类似彩虹字典，大数据暴力破解这些，你知道吗？
|
 |
6
silverbooker 2019-07-16 11:49:54 +08:00
简单的办法，可以先对其中的某个参数先进行一次 md5，再拼接，再整体 md5。
|
|
8
GGGG430 OP @silverbooker 多层 md5 我在以前的一个 webshell 中见过，意义不大，黑客无非多破解一层即可
|
 |
9
xingyue 2019-07-16 11:54:54 +08:00 via Android
md5(md5(key+md5(key)))
|
|
10
GGGG430 OP @leo108 signature 的长度无非就是付出与收获的正比，当某个接口的数据足够重要，再长的长度也就没有了意义
|
 |
11
lshero 2019-07-16 12:02:58 +08:00
彩虹表都是针对于常见密码制作的，urlencode 后请求参数这些光&符号和=号就已经不符合一堆彩虹表的制作习惯了。
一般 md5 前会约定秘钥(salt) 才是决定接口是否安全的因素之一，一般的 salt 可能是约定好的字符串也肯能是请求头中的某个参数 客户端和服务端会约定参数中加入时间戳，超过一定时间窗口的请求会被服务端丢弃的。 而且有些接口会让你添加一些随机字符串防止相同参数相同请求生成的签名重复 接口使用签名保护接口核心就是需要保护秘钥不泄露，其次才是考虑如请求重放服务端是否需要考虑幂等性之类的至于彩虹表压根不会在考虑范围 |
 |
14
micean 2019-07-16 12:14:06 +08:00
什么价值的服务值得去破解 md5 ？
|
 |
15
summerwar 2019-07-16 12:14:14 +08:00
参数到一定程度的时候，预先算出的彩虹表请问用什么来装？全球的硬盘都不够用，谁会无聊存那么多彩虹表，你怕是对彩虹表有什么误解吧
|
 |
17
geelaw 2019-07-16 12:20:01 +08:00 via iPhone
恍惚间以为自己活在上个世纪。
2004 年开始，MD5 已经不能用于任何需要安全性的应用密码方案。 另外楼主语焉不详，请详细描述你需要的安全措施具有的语法、正确性和安全性，然后搜索业界成熟的解决方案。 |
 |
18
MiffyLiye 2019-07-16 12:25:41 +08:00
加 timestamp，用 sha256
const signature = crypto.createHmac('sha256', signingKey).update(timestamp + parameters).digest('hex') |
|
19
GGGG430 OP |
 |
20
aWangami 2019-07-16 12:32:04 +08:00 via Android
@GGGG430 别人给你正常的建议你怎么一条都没回呢？加个时间戳就解决了大部分问题，复杂一点上公私钥。还有，没有人会用彩虹表去破解你的签名的
|
|
21
GGGG430 OP @aWangami 没回复是觉得不够安全, 另外这个接口使用很广, 已经有爬虫破解过多次 signature 了, 目前在处理服务层反爬虫+业务接口层校验参数
|
|
22
lshero 2019-07-16 12:43:31 +08:00 1
反爬虫和签名的安全性真的没关系
你需要的是限制客户端账号的访问频率、增加识别是否为人类的验证码、数据中隐藏陷阱并吐出脏数据 |
|
23
MiffyLiye 2019-07-16 12:44:49 +08:00
前端程序都是公开的，signingKey 你准备怎么藏起来
|
|
24
GGGG430 OP |
 |
25
loading 2019-07-16 12:51:18 +08:00 via Android
楼主，加 slat 了解一下。
|
 |
26
luckyrayyy 2019-07-16 12:53:01 +08:00
多层散列没有任何帮助，甚至有可能降低散列效果。
另外高安全性的东西肯定不能这么用，但是一般的接口，这个彩虹字典得多打才能破解得了啊，就算能行成本也太高了吧 |
|
27
luckyrayyy 2019-07-16 12:54:43 +08:00
哦我搞错了彩虹表的作用，楼上说得对加盐可破
|
|
28
GGGG430 OP @luckyrayyy 也许对方是通过反编译客户端来获取到的密钥 key, 被破解几次后不再相信这个了
|
 |
30
chinvo 2019-07-16 13:04:26 +08:00 via iPhone
大兄弟，反爬虫和 API 安全 无关
反爬虫是行为分析问题 |
|
32
micean 2019-07-16 13:05:34 +08:00 1
“爬虫破解过多次 signature ” 说明是密钥外泄而不是被破解
应该像#22 那样限制每个客户端访问频率，签名是保护接口参数不被篡改，而不是防止被第三方调用的 |
 |
33
yongliu 2019-07-16 13:10:30 +08:00 1
@GGGG430 爬虫破解的时候十之八九不是用的彩虹表，而是分析逆向你们前端代码得到的。看起来反爬虫才是你要解决的问题，而不是 signature 是否安全。signature 能解决大部分的问题，至于爬虫，你们可以通过更复杂的校验方式去识和处理，比如限制 ip，限制 cookie、限制 user-agent、前端代码混淆等方式组合处理。
|
 |
34
Vegetable 2019-07-16 13:15:10 +08:00
闲的蛋疼吗这不是，我为什么要花那么大代价搞字典去破解你的签名，而不是反编译你的客户端？你自己把路走窄了，妄图通过签名来提高接口的“安全性”，这路子不太对吧。最关键的还是因为客户端跑在客户手里，你如果想反爬，应该走#22 说的路子才对
|
|
35
silverbooker 2019-07-16 13:54:46 +08:00
@GGGG430 你可以整体 md5 套 上部分参数 md5 再设计一些 shuffle 规则再加上 shuffle 规则动态更新，用彩虹表肯定是破不了的。不过做爬虫的人可是不会用彩虹表来破签名的，都是直接逆向反编译静态分析或者下钩子。
如果是 App 的话，可以看看一些商业壳。 如果不是的话，可以了解一下瑞数动态加密。 |
|
36
GGGG430 OP @silverbooker 嗯, 增加加密规则复杂度感觉在反编译 /逆向破解面前用处不大, 对方既然可以看到 key, 那也可以看到客户端的加密规则, 目前处在鸡肋的阶段中...
|
 |
37
mritd 2019-07-16 16:49:51 +08:00 via iPhone
这种东西抛开业务空谈没有意义，加密强度取决与业务重要性，你就传个头像地址疯狂加密有啥用？所以没业务场景在这空谈没意义
|
 |
40
welling 2019-07-16 21:45:21 +08:00 via Android
题主是没看懂 3 楼的话吧
|
Select Language