@MinQ 我刚试了一下，没发现有什么问题。

ALTER TABLE table1 ADD INDEX REVERSE(col);

@MinQ 记错了，那就是 CREATE INDEX idx1 ON table1 REVERSE(col1);

REVERSE 是对针对字符串处理的。

@MinQ "mysql 是没有优化的，需要自己新增，比如取前 N 个 reverse 然后存下来"
新版本已经加上了，有新的创建 index 语法, DESC 关键词, 不用手动 reverse 。

"第 5 条附言 20210414-0320 总结：国内还是偏向一定要有『签名』的多，不知为何。"

楼主说了那么多不签名的理由，我就问一句，你的客户在电子支付过程中出了金钱问题，你作为设计支付 API 方，赔不赔钱？

什么？你没钱？那还不赶紧加上签名。（国内签名现状）

@johnsona "加一列把原来的列 reverse 一下 这样就能用到索引了（ bushi"

我觉得 reverse 这种，新数据库已经自己优化掉了。要不然 2000 万条数据无索引暴力查询，不知道慢到什么程度了。

@dzdh "所谓的『签名』是 HTTPS 自有特性，已经完全可以满足安全需要。"

所谓 HTTPS 的签名，只是针对证书验证环节，又不是对具体发送内容进行签名验证。

就像你说的 F12 被修改问题一样，HTTPS 内容还是要解密落地后才能让代码处理的，为什么要让中间商赚差价？如果发送内容都 end-2-end，终端对终端签名。我就不信普通黑客，能轻松修改银行的数据包。

看论坛右边的技能冷却条，睡一觉起来就可以了，今天刷了不少回复，我的也快满了。

@chinvo 上海电视台有个节目叫案件聚焦，有一期就是黑客修改银行的 HTTPS 抵押贷款数据，把原本抵押资金从 50W 改成了 50 元。然后赚了几千万，无数辆跑车，因为太贪心被银行报警抓了。
我不知道他是如何做到篡改加密数据包，怪只能怪银行开发码农和楼主一样，对 SSL Pinning 和 HTTPS 来的数据，太过自信了。

@dzdh "HTTP 的签名机制完全没有存在的必要"

有必要，老外说的很清楚，签名机制纯粹是为了 end-to-end integrity，为了 meaningful for the application 。不管中间乱七八糟的 TLS 网关，一切的签名，只为和我对接的终端所负责。

@chinvo "我选择增加额外的验证逻辑, 比如 Signing HTTP Messages"

我去看了一眼，RFC 里完全解释了 TLS 不可全信。(for example, if the application is hosted behind a TLS-terminating gateway or if the client is behind a TLS Inspection appliance)

楼主就是死不承认有 TLS 解密网关的存在。都 2020 年了，http 签名还是浮上了水面，强烈支持啊！

@dzdh "对啊？别说加密了，还搞开发干啥。管你什么 KEY 你数据库里总有吧？"
保存 key 可以靠操作系统的权限来隔离，windows/mac 搞了那么多年的 keychain，总比存数据库要安全一点了。
linux 系统 root 提权很难很难； windows 系统上，你 chrome 保存的网站密码文件泄露后，换台 PC 没有对应解密 key，神仙也解不出来。

@dzdh "客户端环境都木马了，你的签名 KEY 还有何安全可谈？"
木马一般都是定向功能，比如能盗取 HTTPS 数据流并解密，又不一定能成功偷到商户 KEY 。

前几天有个类似安全贴子，讨论数据库被脱裤，数据加密还有什么意义？
回帖都表示，黑客只靠一个漏洞，要同时盗取数据和对应的解密 KEY 是有一定难度的。能黑进数据库，往往不代表能同时获取 KEY 。

用于 URL 签名的商户 KEY 也是同理。

@dzdh “请从『纯技术角度』来『『证明』』 HTTPS 不安全”

上面提到过，SSL 的安全核心依赖的是 hmac 的 key，俗称 master secret 。如果你电脑里这个硬件内存地址被泄露了，那所有的包都是能成功解密的。

你可以确保自己的服务器万无一失，可客户服务器凭什么去保证不会被挂什么木马？

安全从来就是相对而言的打分制，支付 API 加上 url 签名，哪怕只能提升一点点安全系数，那也是值得的。

@dzdh "论点到底是什么。"
写那么多，就是回复你的那句：“我的$ukey 在公网传输，有 https 保证不被泄露”

我结论就一句话: 不传最安全。

@dzdh "？？？ 加速只是『计算』 TLS 通道仍然是『绝对安全』的。"
RSA 加速卡就是 TLS 解密用的，你只能保证服务器到服务器这段距离是安全的，不会被运营商插入什么奇怪东西。但没办法保证客户集团网关解密后的数据流，是绝对安全的。

这和你 API 设计机关算尽，却防不了内鬼同事是一个道理。

@dzdh "我的$ukey 在公网传输，但是有 https 保证不被泄露啊？有什么问题吗？"
今天 V2 有个帖子，说的就是 chrome 现在版本的本地执行代码漏洞，光 JS 代码，就能成功调出用户电脑里的计算器程序。理论上 chrome 用户人数最多，版本更新最快，应该更安全，可事实却不是。

正所谓道高一尺，魔高一丈。

你说 https 保证$ukey 在未来不被泄露，这真不太好说。现在全民普及 SSL，大厂为了性能，会专门买那种 RSA 加速卡，设置一个专门网关来加速大批量 SSL 处理过程。一旦 SSL 经过了中间转手，一切都无法 100%保证了。

这种转手对于 SSL Pinning 是无感知的，因为和你交换证书的网关，背后有无数机器，不是一台单独 PC 。

@dzdh “curl -u $ukey”

商户 key 不是这样用的，商户 key 是 hmac 算法的关键。SSL 里同样也有 hmac 算法，key 叫 master key，如果你有幸拿到了，那恭喜你，就真正意义上攻破了 HTTPS，喜大普奔。

@dzdh "比如我微信支付商户的证书公钥你要吗？我发给你。"

微信没有公钥，在 url 签名算法里，只有商户平台设置的密钥 key，这个绝对不能发给别人，绝对不能在网络上流传，必须严格保密。

公钥和商户 KEY 的区别，就好比一台联网的 PC 和一台物理断网的 PC 差别，你说哪一个更安全？

@dzdh “2. SSLPinning”
你这就是先有鸡还是先有蛋的问题，SSL Pinning 的前提，就是双方验证对方的证书。然而你证书不发送出去，又何来验证一说？但是你一旦发送，你的客户端证书就有可能被泄露。

学一下微信 KEY 多好，只签名不发送，稳妥多了。