这是一个创建于 414 天前的主题，其中的信息可能已经有所发展或是发生改变。
今天看到百川大模型的接口文档 https://platform.baichuan-ai.com/docs/api 中要求对请求内容和时间戳进行签名，想到前几天在 V2EX 看到的帖子吐槽腾讯大模型 API 的签名( https://v2ex.com/t/975832 )。
而我们去看 OpenAI 等公司提供的 API ，是不需要这种签名的。
所以想讨论一下，在 HTTPS 时代这种签名是否还有必要？还是一种思维惯性？
我的理解：在 HTTPS 之前，这样的签名可以有效防止请求内容被篡改，是很有必要的，但现在 HTTPS 普及了，这里的好处并不存在了。另一点是重放攻击，我了解不多，请懂的朋友讲讲。
第 1 条附言 · 2023-09-27 08:25:36 +08:00
本贴不是讨论是否有了 HTTPS 之后不需要任何签名，而是讨论如百川、腾讯这两个例子里，对其他开发者提供 public API 时，是否还需要这种对请求体+时间戳进行签名的方式
 |
101
cosiner 2023-09-27 11:29:04 +08:00
HTTPS 是保证链路安全, 请求签名是鉴别请求者身份的, 作用都不一样
|
 |
102
Wetoria 2023-09-27 11:33:42 +08:00
昨天看到了，今天还在讨论😂。
客户端加密不就是为了防止接口被不信任的人调用嘛？做过爬虫就知道了。有签名和没签名的平台，实现爬虫的工作量完全不在一个量级。 https 防止的只是在传输过程中，数据不是明文，不被直接曝光。 |
 |
103
LynFt 2023-09-27 11:34:51 +08:00
@xmumiffy ssl 防的是第三方,签名防的是用户自己.按照银行保险柜来举例子,我老婆也知道保险柜密码,现在我和她离婚了,你怎么防?
|
1 |
108
brader 2023-09-27 11:40:08 +08:00
有必要，而且是有使用场景的。
比如某些不需要登录的公开 API： 无签名机制：直接抓包工具抓到接口就可薅你接口的羊毛。 有签名机制：抓包抓到接口无用，还需要反编译你的 APP ，并从混淆过的屎山代码中，找出你的签名规则部分的代码，才可薅你接口的羊毛。 虽然最终结果都是可被破解的，但我们能看到，有签名机制，增加了破解难度，可以拦截掉一大部分只是尝试心态、无能力或者无时间、无精力去反编译代码找签名规则的人。 |
 |
109
xmumiffy 2023-09-27 11:44:20 +08:00
@brader
你不需要什么抓包工具啊,api 文档公开网上随便下. 你的破解难度就在于怎么获取到一个有效的 api key . 你能拿到一个有效的 key,不管有没有签名都一样能用,最多就是要照着文档写一遍签名. 然后一般服务商都直接提供 SDK 帮你写了签名函数.你看服务商多好,还帮你去破解他. 或者你只是看了标题,没看内容. 这个问题讨论的不是客户端 API,而是服务商提供给别的开发者用于服务端的 API. |
 |
111
wuwukai007 2023-09-27 11:48:18 +08:00
参数签名加密，如果数据比较重要，对爬虫还是有点效果的
|
 |
112
momocraft 2023-09-27 11:57:20 +08:00
讨论到现在看到的真实好处也就一个增加爬取成本
而且这是公司的好处，不是密钥没泄漏的客户的好处 说到底市场定位不一样 有的公司比如企鹅，客户捏着鼻子也得用 有的公司可能觉得自己是企鹅，或者觉得像企鹅一样折腾客户就能成为下一个企鹅 用户方便不方便最不重要，毕竟人的时间不值钱 |
 |
114
liuguang 2023-09-27 12:11:58 +08:00
请求签名是为了证明是你调用的，而不是别人。方便区分用户，如果不签名，别人就可以冒用你的身份。
|
|
115
Wetoria 2023-09-27 12:13:44 +08:00
|
 |
117
GuangXiN 2023-09-27 13:18:18 +08:00
几乎所有的 https API 都不会要求通过客户端证书建立 TLS 连接。apikey 、access_token 在每一次 API 请求时都会在网络上传输，只要一次 MITM 攻击就可能泄漏，风险较高，所以一般设计有效期都不会太长。secret 一经颁发就长期保存在客户的服务器上用于签名，不会再通过网络传输，泄漏的风险小很多。
|
 |
118
dayeye2006199 2023-09-27 13:55:14 +08:00
X 经问题，我之前也问过： https://www.v2ex.com/t/868678#reply64
结论是：给恶意使用者制造一点麻烦，但是基本防不住厉害的东西。 因为别人都这么干，所以我也这么干就对了 |
 |
119
likunyan 2023-09-27 14:16:18 +08:00
需要，增加被攻击的成本。
|
 |
120
iseki 2023-09-27 14:19:46 +08:00 via Android
只会增加开发成本，没必要
|
 |
121
fengw233 2023-09-27 16:21:29 +08:00
https 是可以被劫持的，可以通过攻击请求方拿到请求数据向 api 发起重放，签名可以避免身份验证信息明文传输 以及防止重放攻击
|
 |
122
GeekGao 2023-09-27 16:27:53 +08:00
如果接口已经使用了 HTTPS(HTTP over TLS/SSL),那么参数签名的必要性会降低一些:
HTTPS 本身就可以防止中间人攻击,数据传输在加密通道内,参数不易被篡改。 但 HTTPS 无法防止客户端篡改参数后再发送请求的情况。此时参数签名可以作为最后防线,检测参数是否被篡改。 一些特殊攻击如重放攻击,HTTPS 也无法直接识别和防护。参数签名可以识别非法重复请求。 如果应用很关注请求参数的完整性,并且接口对传入参数做进一步校验使用,那么签名依然可以作为辅助手段。 所以,如果仅仅考虑传输安全性,在使用 HTTPS 的前提下,参数签名的防护效果会受到一定程度的冲减。 但总的来说,参数签名作为一种应用层的安全机制,它的价值并不完全取决于传输层是否使用 HTTPS 。 如果成本允许,最稳妥的做法是: - 使用 HTTPS 加密传输 - 加上参数签名的验证 - 合理限制接口调用频率 - 以获得最全面深度的防护效果。这种多层防护的合作也是 RESTful 接口安全设计的一个好习惯。 |
 |
123
me1onsoda 2023-09-27 16:32:22 +08:00
@xmumiffy #116 "这个问题的关键在于 HTTPS 链路上可不可以明文传递 key"
key 加密有什么意义？加密方式都是公开的对称的，谁都能解开 |
|
124
xmumiffy 2023-09-27 16:37:50 +08:00
@me1onsoda 还是看下题目吧,这里说的是 api-key ,key 压根不用于加密,明文传递 key 用于确认身份的.
|
|
129
xmumiffy 2023-09-28 09:15:25 +08:00 via Android
@rekulas https 防的不就是中间人攻击，能攻破 PKI 的看的上我的接口那我也太成功了，市值怎么也得先超过苹果加谷歌之和吧。
|
 |
130
CRUD 2023-09-28 09:57:03 +08:00
@rekulas #126 问题是你拿不到数据，这种情况下，中间人能拿到的顶多就是 HTTPS 的密文，密文拿到了你也没法修改，想要拿到明文数据，除非你入侵到本机，在发起端上添加对中间人证书的信任。
|
 |
131
rekulas 2023-09-28 12:52:44 +08:00
|
|
132
xmumiffy 2023-09-28 13:49:02 +08:00
#131
那看来我们是鸡同鸭讲了,他只了解他做的有关 APP 端的东西,对其他事务一点也不了解. #127 中我就已经说了这里讨论的是服务器端的 API,并不是 APP 端的. |
|
133
CRUD 2023-09-28 13:49:44 +08:00
@rekulas #131 我一开始就说了是服务器对服务器单向调用的情况下，回答的是题主说的 public API 的场景，你非要说其他场景，那签名也却有其存在的道理。
|
 |
135
hanyuwei70 2023-09-30 09:12:07 +08:00 via Android
@cheetah 简单讲就是防篡改，为什么在 https 下还需要防篡改就要自己看原文了
|
Select Language