HTTPS 用明文传输密码的问题，看到很多次了，个人观点不赞成，单开个帖

[lesismal]

在隔壁 #71 #74 回复过了，但估计很难被人看到，所以单开个帖： https://www.v2ex.com/t/1043320

github 的问题也不是没被暴出来过： https://zhuanlan.zhihu.com/p/36603247

单就传输信道而言，https 能解决中间人问题，明文在这个用户前端到厂商之间的 https 信道范围内没问题。 单就 github 而言，因为有二次验证，所以即使拿到密码了换个设备也登陆不上，所以有一定合理性。但 v 站没有二次验证，用明文我个人观点不太赞成

安全不只是传输信道，传输信道中间人之外还有社工、复杂的人生场景，例如有人借用你电脑的时候给你设置了个代理或者装了马拿到了你的帐号密码，以后说不定做什么坏事，这就属于传输信道之外的安全场景了。

用了 https 就明文只解决信道安全问题，用明文至少意味着：

1. 用户应该尽量管理好自己设备的安全
2. 用户到厂商之间的 https 信道之外的处理流程上，厂商应该确保安全，例如上面引用的文章里提到的 github 爆出来的问题

另外更简单的一个思考，如果不用明文、我们实现上增加了什么成本，带来了收益，有什么损失？

1. 成本：几乎没有增加额外成本
2. 收益：安全强度提高了
3. 损失：安全上没损失，但厂商不知道你明文，至于厂商知道你明文有什么好处，自己脑补吧

很多人都是觉得：有人用明文，尤其是有大站例如 github 用明文，所以就是对的，根本没考虑过信道之外的安全，也没有考虑大站是否有额外的安全策略例如二次验证，也没有去统计对比，是不是所有大站都用明文、或者用明文的大站占据绝大多数，也没有去区别不同站的类型和对安全的需求等级，比如是否涉及资金安全的，例如金融类、电商类相关的接口

再用脚想一想，如果 https+明文就安全了，为啥还要有二次验证之类的额外的安全策略？

[cybort]

@790002517zzy 关键不是能不能获取到加密方式，而是不同网站的加密方式不一样，拿到的数据没有重用价值。

[viruscamp]

我见过几种 https 基础上用户侧密码加密的几种方案
1. 前端密码用固定的 hash 算法固定的 salt ，算出哈希后传给后端。如 @cmdOptionKana 所说：那么密码就是这个哈希值啊
2. 前后端协商出一个临时密码（包括前端随机一个给后端，后端随机一个给前端，某种基于时间的算法前后端同时算出），前端加密密码传给后端，后端解密。我的评价是，脱裤子放屁，发明了一个很不安全的 https
3. 更聪明一点，前端有后端给的公钥，时间+密码，加密后给后端，后端解密，验证时间(30 秒内)，得到密码。抓包得到的加密字串每次都不同，而且有效时间很短，如果后端短期内记录使用过的密码，有效期内的重放攻击也可以基本解决。这个思路，必须再往下走，前后端交互公钥，所有传输公钥加密，那么这离真的 https 基本就差安全的公钥验证了。

[Bingchunmoli]

@IvanLi127 代理你 rsa 加密就不会明文，不加密就是明文， 这个场景举个例子就是路由器不信任或者说路由器这种被攻击，设备可信但网络不可信（另外一种可能公共网络）

[IvanLi127]

@Bingchunmoli 你不觉得上下文全拿到就能解密还原么...不然咋交换的 rsa 密钥。

更重要的是，如果是针对特定场景攻击的话，对于网页来说，你以为你你被监听，实际上你根本没有访问目标网站，而是攻击者的站点，加密不加密是不可信的中间设备决定的...这个很明显加密解决不了问题了，人家可以轻而易举地把加密去掉。简陋的形式类似用官方域名的钓鱼网站

[msg7086]

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

[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 ，不做这件事就会造成公司损失，否则没人会鸟你。

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

[msg7086]

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

但……

[holulu]

"为什么 Amazon Web 不用明文? 为什么淘宝 Web 不用明文? "这个感觉是不是在 https 还没普及的年代才这么干的？后来 https 普及了，但这些厂商懒得改，就继续沿用而已。
另外就是 OP 多次提到设备借给别人使用，然后被挂代理或抓包拿到密码的情况。如果都被中间人攻击了，还需要拿到你的密码吗？而且不理解为啥把自己的设备借给别人用，手机和电脑难度不是像身份证和银行卡一样重要的吗？

[bullfrog]

建议 lz 保护自己的指纹，平时都带上手套，这样没有什么额外的成本但是安全强度提高了

[NoKey]

@msg7086 密码攻防这一块，一直以来的一个基本理论就是，算法代码本身起不到保护作用，非对称加密算法都是开源的，保护秘密的本身是密钥，不是算法

[Bingchunmoli]

@IvanLi127 rsa 怎么会交换全部密钥呢，如果交换全部密钥还是非对称加密吗

[IvanLi127]

@Bingchunmoli 抱歉，当对称加密了.... 那就只能针对攻击了。

[plko345]

支持非明文，虽然说不出太多理由，也无法反驳坚持明文的观点，但还是强烈支持

[crystom]

这是微信小程序的推荐设计，是要加一层的： https://developers.weixin.qq.com/miniprogram/dev/framework/open-ability/safe-password.html

[8520ccc]

实在想加安全性，那就 使用公钥加密 hash 值+时间戳+随机数 这样即使拿到密文数据 也能防止重放攻击

[kenvix]

首先肯定是不安全的，这我非常赞成。
不过出于实现成本的考虑，我仍然明文传输

[cmdOptionKana]

@Anarchy

> 作为被 CSDN 脱库都受害者，还是希望开发者们至少对密码多下点心

注重密码安全是应该的，比如后端不要储存明文密码就是因为拖库事件而逐渐成为行业标准。

但注重密码安全不等于做无用功搞心理安慰，“前端加密密码”这种行为相当于在机房摆个香炉祈求神佛保佑安全，都是心理安慰，不宜提倡。

[iyaozhen]

@kenvix
@viruscamp

我和两位老哥观点一致，作用肯定是有作用的。但要想大范围推起来，还是很难的，就是有成本（不仅仅是技术方案）。

HTTPS 能推起来我始终觉得浏览器（不记得是不是 chrome ）功劳最大，如果它不提示“不安全的”几个大字，到现在都可能还是 http 为主

[lesismal]

> 你就不能推进网站后端采用 bcrypt 或更安全的验证算法，推进网站后端 log 脱密记录？

@viruscamp
bcrypt 本身也是非明文的方案之一, 我没有抵制过使用 bcrypt, 是否采用 bcrypt 的阻力有两个, 一是团队有没有人懂安全, 二是 bcrypt 性能, 所以 bcrypt 也就回到了大家都比较认同的安全级别问题上了. 对于 FIN Tech 相关的安全级别要求高的, 用 bcrypt 即使登陆的时候慢那么一点点也无所谓, 但是对于安全级别要求不那么高的并且并发量在线量大的, 可能就不会采用 bcrypt

至于后端 log, 这个我相信多数团队都有要求, 但是你没办法避免开发人员或者有心之人假装无心 log 打出来了, 再采用明文的项目里, 这额外需要严格的研发流程把控, 而如果本来就没采用明文, 就不需要这个额外的流程把控, 你觉得哪种更划算?

[lesismal]

> 就拿我司我们 org 的习惯来说吧。如果你要做一项比较大的功能改动（你说的前端加密就已经是比较大的改动了），一般需要先开一个 wiki page 把改动写在文档里。

@msg7086 我现在明白一件事了, 因为你门大部分人的项目, 本来就选择了明文, 如果用户和业务量非常大, 即使改造方案没问题, 但也是担心规模效应, 所以确实成本大. 但我们并没有局限于旧项目改造, 新项目如果从一开始就应该使用非明文方案. 如果你们团队一开始就明文了, 那说明最初负责技术的人本身他就不够严谨

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

你有没有想过, 很多黑产搞到东西, 但每年我们看到的新闻有多少? 被你知道的泄漏了的只是冰山一角, 你没看到不代表明文就安全了, 也不代表改造后就没带来更全的安全性.
另外, 黑产最高级别是社工, 从企业到政府国家之间的渗透, 很多技术上安全做得非常严谨的仍然被渗透过就是通过社工, 比如后端开发假装失误把日志里打印出了明文的用户信息并且盗取出售, 事后即使企业发现了整改了, 后端内鬼也只是说不小心失误了, 你不能保证所有项目所有流程都严谨, 即使流程都严谨, 也不能保证执行过程中完全没有疏漏.

前阵子那个压缩算法开源项目贡献者潜伏成维护者然后投毒热度刚过, 不要没被烧伤就不知道疼, 不要好了伤疤就忘了疼