@timedivision

所以是，仅仅 HTTPS 已经足够安全，所谓签名只是锦上添花？

@3dwelcome 91

如果有签名的时候被黑了呢，接口 bug 了呢 这不是一样吗

@3dwelcome 90

> 管他有没有用
所以并不是出于安全考虑，就是为了『加』而『加』？

> 你用国外网站举例没意义，国外信用卡支付没密码是安全的，放国内基本不可能
公共网络的、任何人都可以进行调用的、处于公网环境的 HTTPS 接口，甚至有详细的文档。为什么他就『安全』呢？支付宝接口如果不用『签名』设计就『不安全』了？比如如果支付宝现在开始不用签名了，会导致什么问题呢？包括但不限于下单、退款、关闭订单、转账等接口，就直接像 stripe 一样 `curl -u $key https://api.alipay.com/api/transfer?to=xxx&amount=1000` 。

@newmlp 88

> Server 端到 Server 端。

同理，HOOK 也可以轻松拿到用于『签名模式』的签名密钥，so easy~

@ashuai 86

"有以上可能吗？如果有，这就是签名的意义"

没可能

@jhdxr

在思考这一点之前，先思考如何保证『签名模式』下对方一定也是 Server 端。

我的接口是为了 Server 端调用而设计，客户错误使用暴露出去，屏蔽 ClientID （调用凭证）即可

@xuanbg 64

同理，如果客户端环境安全无法保证的前提下，怎么保证『签名模式』是安全的呢？

@hxndg 有理。

@VHacker1989 55

所以安全就不用做了呗？无论你做任何安全都可以被逆向、动态调试？

@no1xsyzy 54

- SSL/TLS 不能确定对方是否对你的证书进行了验证。
回： ？？？

- 双边证书使用相对麻烦。
回：签名排序参数使用密钥拼接参数字符串不麻烦吗？

- 然后还有遗留问题和习惯问题。
回：如？

@borisz 52

所以 paypal 和 stripe 两个平台是极度危险的是吗？

@kejialiu 51

HTTPS 防止中间人有 SSLPinning 的方案，足矣无限接近 100%的保障安全（请提出反对意见）

- https 服务端的密钥是怎么管理的，都有谁经手了，不小心泄露了呢？
回：签名模式的密钥怎么管理的？都谁经手了，不小心泄露了呢？

- 浏览器这样的客户端是否可信任呢？里面会不会装了莫名其妙的插件钩子呢？
回：Server 端到 Server 端，签名模式就能规避『莫名其妙』的钩子是吗？

- 签发 https 证书的 CA 是不是足够可信任呢？
回：本地指定 CA 文件验证


根据你的应用的敏感级别，这些可能都是需要考虑的因素。比如 Google 的安全原则是所谓 n+1，意思就是你总是要多做一层防护，让不明真相的程序员在做错了 n 件事的情况下仍能保证安全。
回：所以是 HTTPS 足矣保证安全，仅仅只是为了多加一层兜底手段，对吗？

@kejialiu 49

比如？

比如下单场景，可以要求调用方生成唯一『请求号』，在接口设计逻辑上可以进行规避。

有没有什么场景是『无法』进行规避的？

@timedivision 48

请阐明就目前技术手段方案中，HTTPS 前提下，签名模式的『必要性』

@David1119 47

接口设计要求 CleintID，爬虫场景完全可以屏蔽 ClientID 。

其次，标题是 Server 端到 Server 端。即便是用户不小心暴露 API，依然可以屏蔽 ClientID，中断爬虫行为。该理由不成立。

@wentx 46

Charles 是依靠『中间人』来进行抓包的。

其次，如果真的使用 Charles，那是不是就意味着其已经控制了『物理机』？在控制『物理机』的前提下还有什么安全方案是可以保证『全安』的吗？ 并不能证明 HTTPS 环境下，签名模式的『必要性』

@newmlp 44

同理可证明，如果客户端不安全（如『签名模式』的密钥摆在明面上），那『签名机制』远没有『 HTTPS 』安全。该理由不成立。

@keyfunc 43

密钥泄露和签名所用的密钥泄露是同等效的，那同样也不能证明『签名机制』的安全。该理由不成立

@Telegram
几楼或者哪句话有『不需要账号密码』的意思，请指出。