msg7086

其实刚刚又想到个事。
加密通信的时候，加密的算法和代码要不要保密或者混淆？
可能有人会觉得，加密算法当然应该保密，攻击者拿不到加密解密方法，那不就安全了吗。

但……

针对 append 部分
一共三个 part: client 端的安全, 传输信道的安全, 传输信道之后的 server 端所有流程的安全. 这其中不只是技术本身的算法流程, 最高可以到社工范畴
你们很多位, 只盯着 1 或者 2 个 part 说没用. 但目的是让完整链条的安全级别提高.
即使不用明文并且增加各种额外手段也不能 100%, 比如绑架了. 但用明文是为了在技术上让完整链条 3 个 part 的整体安全级别更强一些.
所以, 我建议各位, 不要只拿出一个 part 来说用这用那都没用.

==========

我感觉你说了这么多还是没讲到点子上。我觉得你最好重新整理一下自己的思路，否则就我看评论区的样子大家都在各说各话，讨论不到一块儿去。

就拿我司我们 org 的习惯来说吧。如果你要做一项比较大的功能改动（你说的前端加密就已经是比较大的改动了），一般需要先开一个 wiki page 把改动写在文档里。
文档分几个部分，首先是摘要，说明现状如何，遇到了哪个具体的问题，会造成什么样的后果，产生什么样的经济影响。（比如出了一个 bug 造成 3 个客户的业务离线各 3 小时，这就是经济影响。）然后是你的大体设计，这里一般简单说几句画个流程图什么的就行了。然后是产生的实际影响，比如说原本一个 bug 造成某个操作需要花 3 小时跑完，修复了 bug 只要 1 小时就能跑完，等等。

从我读你帖子和回复的内容来看，我并没有看到（ 1 ） HTTPS+明文这样的设计会造成很大的经济影响（例如大规模密码泄露，账号被盗等等），（ 2 ）你设计的解决方案会产生什么样的经济影响（例如原本 v 站大量账号被盗，经过你事故分析，确定是明文传输造成的，如果做了你这个方案，账号就不会被盗了等等）。

如果这是你自己的个人项目，躺在沙发上看电视无聊了突然一拍脑瓜想到了这个方案，爬起来给自己网站加上，这倒是无可厚非的。但是对于正规的企业级项目来说（不管是 GitHub 也好百度也好还是 Amazon 也好），一个 Jira 的立项是需要 business justification 的。就拿我们组的项目来说，修改一处很小的逻辑，也要经过（ 1 ）事故单或者 Filer 提需求（ 2 ）需求分析并撰写 wiki page （ 3 ） Manager 和 Tech lead 审核批准，如果是跨部门的单子还需要其他部门的底层员工和 Manager 签字（ 4 ）确定上线时间，和 Release Management 沟通（ 5 ）写代码，然后为代码写测试覆盖（ 6 ） Peer review （ 7 ）开服务器然后组内测试（ 8 ） FullTest 自动化测试（ 9 ）质量控制组人工测试（ 10 ）运维组人工测试（ 11 ） Demo tenancy 上线测试（ 12 ）分批灰度上线测试（ 13 ）完整上线，正式结案。

当然，不同公司规模不同，流程也不尽相同，但归根结底不要忘记了，加个功能不是拍个脑瓜公司就批给你那么多人工的，工程师又不是天天闲着没事干，处理更高等级的任务都忙死了，为什么要浪费时间处理一个无所谓有无的东西，除非你能说服你的 Manager ，不做这件事就会造成公司损失，否则没人会鸟你。

个人项目，还是那句话，你想做尽管做就是。但不要随便把手指指向别人的项目。这种行为我们有个很常见的说法，叫外行指导内行。

@cybort #160 你说的没错，所以才需要推广密码管理器，一站一码。
前端加密不是解决明文存储密码的方案。毕竟，都为了安全去搞前端加密了，怎么还会去明文存储密码呢……

看了你贴的知乎讲 github 和百度的那个帖子。但是有趣的地方就在于，百度的登录请求的那张图里，其实并没有做过 MITM 中间人防护。也就是说，虽然客户端找服务器拿了公钥，加密了密码然后再发回，但其实客户端并不知道拿到的这个公钥是真的由百度发出。HTTPS 证书世界里，要伪造可信证书是很难的，要是哪个厂敢生成他无权生成的可信证书，没几天他的 CA 就要被全球吊销了。但帖子里讲的这种非对称加密就没有这种认证机制。如果有人有心去主动攻击百度的登录服务，这种额外的加密是不堪一击的，攻击者只要自己生成秘钥对替换掉百度的公钥，然后从用户侧拿到数据解密即可完成密码破解。

其实这帖子我看得很懵，不知道你这个操作到底是要达成一个什么样的效果。

现在我们假设用户的密码是 "3m&y5oDChc"，然后你用 JavaScript 做了一次运算，比如说 md5(password+SALT)，得到 "123456abcdef" 这个 md5 。

你的目标是保护 "3m&y5oDChc" 不被人偷看去，是这个意思吗？

@lesismal 哈希加盐以后，哈希加盐的结果就是密码明文了。

所以你只是想保护用户自己想出来的密码不会被人看见，而不是保证一个能通过认证的密码不被人偷走，是这个意思吗？

我看了看你引用的原贴，似乎是浏览器插件读取了密码。这其实就是一个很典型的明文密码加密无效的案例。盗取密码的攻击者直接把你输入到文本框里的密码读出来盗走就行了，总不能特地等到你前端加密完了再傻傻地去读加密后的密码串吧。

这种你要防的话就要回到 ActiveX 控件密码输入盘的年代了，安全控件读不到文本框的内容，输出直接就是加密的，这才有意义。

> 很多人还是没想明白，多加一步非明文成本没增加、几乎可以忽略，为什么不能多加这点
1.为什么成本没增加。
2.增加到什么程度才够？
就比如你说的多加一步加密没有成本，那为什么只加一步加密，为什么不加密两次，加密三次？为什么没有成本的加密只做一次。
如果加密多次也没问题，那么加密五轮就够了吗，还是五十轮呢，或者五百轮？

上面其实已经有人说了，用户侧加密其实并没有很大的意义，无非是用 5%的成本上升换取 5%的安全性上升罢了。你的帖子的问题就在于你缩小了增加的成本，放大了安全收益，以为这是一个用少量成本就能换取不少安全性的操作。但这种操作在真正学过安全的人眼里根本就不值一提。真正需要偷你鉴权信息的人，不会因为你加了一轮加密以后就偷不了了，而只是让他们多花半个小时把处理加密的行为加到他们的攻击代码里而已。在你为加密了密码传输沾沾自喜的时候，攻击者早就把代码改好了。

> 为什么 telegram whatsapp 网页版不用明文而是其他设备扫码登陆?
因为这才是正确的路线。放弃密码，不要用 what you know 而用 what you have 。

实际上我司（全国排名前五的软件公司）马上就要实施 passwordless 登录了，以后在公司登录账号只需要公司邮箱+手机 App 证书鉴权，不再需要记复杂的密码了。手机 App 则是指纹保护，每次鉴权时按一下指纹即可。
也就是说，邮箱+手机+我的手指，构成了鉴权。

你买 amd64 指令集的 CPU ，那确实是可以看看 Intel 的。
万一 Intel 的电脑出现兼容问题，你还可以怪 AMD 。