@3dwelcome #237

你这又绕回来了啊。

按你说的，让你去搞个接口，用这个方案你是不是敢赔钱？你敢我就敢。这不成了抬杠了吗？

何时强调过『 100%的安全』直说『足够』呢。

我再再换个说法好吧？不要考虑任何因素，就说 RSA 算法这个本身，数学上，是不是足够安全？是，那就对了，不是，请反驳。

@1iuh #235

这就是我的本意 ，就安全来说，已经是足够的。

-t, --time int Seconds to wait for stop before killing it (default 10)

@3dwelcome #232

刚换的 KEY 我又泄露了

@timedivision #231

所以是看公司或企业要进行怎么选择。

我是对的，你是对的，所有人都是对的。没有错的（技术性概念问题搞错除外）方案，只有合适的方案，合适的方案就是对的方案。

@3dwelcome #228

然后刚换的 KEY 我又泄露了。

@3dwelcome #228

怎么定义『短期』。1 天？ 1 小时？ DV 证书重新签发 1-3 分钟。

@Rheinmetal #224

我能想到的只有『没有业务唯一标记的业务』无法防止。否则其他场景像支付下单，你要传调用方本地订单号可防重放，关闭订单传订单号可防重放，但是像浏览器端的 event 日志，那的确没法防，因为请求进来就直接入日志库的。


@3dwelcome #225

这就不对了，那 HTTPS 出来以后还有 http2 呢，TLS 还有 1.0/1.1/1.2/1.3 呢。方案是不停进步的，出了 TLS1.3 也没必要全球废止 TLS1.0 对吧？

如果要『扯中间环节』那就一定要说密钥保全，这又是『客户端环境安全』的问题，我就故意泄露密钥、私钥。绕回来还是『无绝对』。但是这依然不能证明帖子标题是『不足够安全』的，我还是明白不能。


@timedivision #226

所以到底应该怎么定义『足够安全』合『绝对安全』。首先『绝对安全』是不存在的，也没必要也不可能做到『绝对安全』。所以为何标题就『不够安全』，我认为就标题的安全防护策略、手段在所隐含的『安全缺陷』在『签名(mdX/shaX(sortedString+key)』都能找到对应的。这并不能成为帖子标题的方案就是『不够安全』的理由吧？

@3dwelcome #221

『安全』应有『度』，要比极致请参考 210 楼

> 真要说安全大可以硬件加密狗+DNA 验证+虹膜+人脸+物理快递安全设备+面对面认证+指纹授权。一次 HTTP 请求等 10 年，但是这不是『根本没必要』吗？

即便用了上述所有手段就『真的『绝对』安全了吗』？但是也不能因为『无法保障绝对安全』就不做任何措施

在世界公认的 RSA&ECC 保护下已经有了这个『度』适应的安全保障。已经『够了』。

下班回家，离门 10 米自动开门，进屋自动开灯全凭身上一部手机和人脸。都『足够的安全』了。但是如果要说的话，这安全吗？装门干啥？有啥门是一锤子解决不了的？要密码干啥？银行就不能被抢了？我一定会懊悔为什么没装两个门，为什么没给家里装防弹玻璃，为什么没把密码设置成 100 位锁在银行保险柜里。

这不都是因为已经『足够安全了』吗？

就像有人在反复强调客户端的问题，我的观点是：针对于客户端，你任何的安全措施都没用，就像上面所有安全措施加一起，我就愣把密钥给出去，开源放到 github 上你凭什么保护？对客户端来说，也是需要他自己具备『安全自保能力的』。

核心论点是：足够的方案措施

@3dwelcome #219

因此，观点『 https 前提下，使用 data hash signature 签名不存在必要性』。

而你的观点是，后面补一句：『用了会『更』安全』是这个意思么？

@3dwelcome #216

或者我再换个说法。https+不使用 data hash signature 是个极简且安全（你说的不绝对 100%嘛）实施难度最小、接入速度最快、最便捷的方案。可以不？

@3dwelcome #215

参看 215 楼

你的论点是：#203: 你的客户在电子支付过程中出了金钱问题，你作为设计支付 API 方，赔不赔钱？什么？你没钱？那还不赶紧加上签名。

并不是我的论点，我只是用你的问题在求证是否能得出相反的论点。

其次，你说支付宝的『你敢付，我敢赔』没问题，是的，真的非常的好，真的。
竞争对手微信呢？他可没这么承诺吧？而且盗刷新闻也不少吧？最终微信不承担责任的也不少对吧？但是并不能得出『微信支付是垃圾』或者『微信支付不安全』的结论，对吧？

再者，并是因为支付宝『使用了 mdX/shaX(sortedString+Key)』才定的『你敢付，我敢赔』吧？而是其复杂鉴权的风控体系和商业保险吧？个人认为这和主题并无关系。
参看#213 楼

最后：我从来没有任何言论表述过『不承认 https+data hash 』或『不承认 http+data hash 』的安全性吧？仍然请参看#213 楼

请不要漏调任何一个观点

@EminemW #207

不不不，两回事。

无论是否使用签名机制（ mdX/shX(sortedString+key))，恶意请求都可以发起，只是拦截的成本。

@3dwelcome #198

依然没有在点子上。不是『要不要』的问题。而是：

回归本质，在 HTTPS 下是不是必须一定绝对只能真的一定要『 mdX/shaX(sortedString+key ）』不可？不这么干的话这个设计方案就一无是处、垃圾、没用、渣渣、愚蠢至极？

@wy315700 #200

是的，这是客观存在的问题，且不可避免。

但是回归本质，在 HTTPS 下是不是必须一定绝对只能真的一定要『 md5(sortedString ）』不可？

@dzdh @kejialiu #197
补充，我指的签名是：md5(sortedString)

@kejialiu #197

针对可能原因，Paypal 从 2004 年开始提供对外接口开始到现在，经历过 N 次的整体架构升级迭代都没有出一套新的（出新的并不意味废除旧的）接口规范？事实是出了，而且依然是 Http Authentication+OAuth 形式。如果硬要说 Paypal 的设计有问题，那后起新秀 Stripe 呢？ facebook 、twitter 、instagram 等等等等呢？显然这种说法站不住脚。

我并不是要竭力的证明『 HTTPS 就绝对的安全了』而是『在 HTTPS 模式下，没有必要在额外做 hash 摘要签名』的逻辑。

真要说安全大可以硬件加密狗+DNA 验证+虹膜+人脸+物理快递安全设备+面对面认证+指纹授权。一次 HTTP 请求等 10 年，但是这不是『根本没必要』吗？

@3dwelcome #203

不同意，你的意思是说：用了签名，客户损失了我就不用赔钱对么？

@chinvo #195

好吧，那是我误解了，比如什么样的『安全』是服务商要保证的。

抱歉，单次回复次数太多，被限制 1800 秒回复

@3dwelcome #184 #189

所谓的『签名』是 HTTPS 自有特性，已经完全可以满足安全需要。因此，在 HTTPS 本身的数据签名之外的人工二次『签名』是完全没必要的。所谓『网关问题』请参看 173 楼。

新闻就不评论了，不能绝对排除银行犯二 F12 就给改了的可能


@chinvo #188
持反对意见
> 但是服务本身的安全(包括从客户端到服务端的链路上的安全)是服务提供者的义务. (法律上一般也是这样认为的)
假设从客户端到服务端经过了 C -> C1 中继城市核心交换机 -> S1 中继城市核心交换机 -> S 。在 C/C1/S1 任何一端由于网络提供商（和服务提供商没有任何关系）维护问题导致网络终端继而导致某个 C 或者某些某部分 C 无法访问我的服务，需要服务提供商负责吗？是应该责怪我没有备用线路？那极端情况所有备用线路都坏了(网络提供商问题)导致客户产生了巨额损失是需要我来赔偿吗？