请 [吸词] 的作者出来解释一下密码明文传输的问题

@jianchang512 是的，脱裤的例子不对

@rambo92 打印密码？你看 linux/mysql 登录的时候密码根本都不回显，mysql 涉及用户操作的一些语句也不会保存在命令历史中。除了用户自己，任何人都不应该能接触到明文密码。

月经贴

@MorJS 做过几个银行的项目，都要求前端用加密机加密。

@0xC000009F 是的，前端代码加密混淆和传输数据非对称加密等是有意义的，不过感觉重点不在于安全上，更像是用来加大逆向难度防脚本的

担心刮大风把山吹走，解决方法是在山上加一把土。

@FTLIKON
@tsanie
@BeautifulSoap
是的，后端能够得知密码原文是合理的需求，前端加盐 hash 都是逆天。因为这样我可以在哪天倒闭跑路之后把用户的用户名和密码 dump 出来卖给黑客拿去撞库。哦，如果哪个用户跟我 dispute ，我可以直接拿他的用户名密码去其他网站登陆他的帐号给他开盒。

或者你相信任何人都不会做这样的事情？

@Jirajine 大聪明，有没有一种可能，只要是脑子正常的的后端程序员，都不会明文把密码存到数据库里去？
当然你可以死鸭子嘴硬说有的网站就是要拿你明文密码去卖钱，那么有没有另一个可能性，真有网站目的是这个的话，它有一万种方法变相搞到你地明文密码？

1. 我觉得这类帖子只有安全专业的同学的回答具有参考意义，但是目前好像没看到有安全专业的同学来讲讲。搞开发的可以说说自己的见解，但盲目自信的感觉还是不要秀了。

2. 只讨论 https 环境，不问缘由，可以参考大厂是怎么做的。当然大家贴出来的大厂答案既有前端加密也有前端不加密的。

@BeautifulSoap 有没有一种可能，我只是一个负责中间件/负载均衡或者其他什么根本不需要接触数据库的组件的开发，我发现某个组件有 bug ，于是就加了几条 log 把部分请求打到日志里。回头我把这些日志收集清洗一下，我就掌握了大量用户的密码了。

或者你认为任何公司的任何员工都做不到/不会做这样的事情？

有没有一种可能，那一万种变相搞到你明文密码的方式，其实都是一种：以后端能够得知原文的方式传输密码。

@FTLIKON #1
github 的问题也不是没被暴出来过，类似 @YogiLiu #8 说的问题：
https://zhuanlan.zhihu.com/p/36603247

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

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

用了 https 就明文只解决信道安全问题，用明文至少意味着：
1. 用户应该尽量管理好自己设备的安全
2. 用户到厂商之间的 https 信道之外的处理流程上，厂商应该确保安全，例如上面引用的文章里提到的 github 爆出来的问题以及 @YogiLiu #8 说的问题

另外更简单的一个思考，如果不用明文、我们实现上增加了什么成本，带来了收益，有什么损失？
1. 成本：几乎没有增加额外成本
2. 收益：安全强度提高了
3. 损失：安全上没损失，但厂商不知道你明文，至于厂商知道你明文有什么好处，自己脑补吧

@kera0a 有的浏览器会收集 url 的 get 请求

@Jirajine
有没有可能，中间件往 log 里打印所有请求体以及返回值这件事，本身就是一个项目中极高等级的重大安全隐患？当一个项目中有组件不分青红皂白把 payload 往 log 里打印的时候你竟然只关心密码？你所有的个人信息，姓名，住址，银行卡号，令牌以及其他关联服务的令牌等等所有一切信息都会被输出到 log 。那么如果按照你的顾虑，为了防止中间件有恶意内部第三者，是不是不光密码不能明文，所有请求内容也要一并加密？

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

再用脚想一想，如果 https+明文就安全了，为啥还要有二次验证？

@lesismal 你去设置里是有 2FA 的

大站用了未必是对的。从信息的角度，能提供验证的信息，就无需暴露出更多的信息(登录)。楼上各楼也总结了，服务端的日志，很多 url 的收集插件。我的观点暴露用户的明文密码，非常不专业。

@BeautifulSoap 是的，当你提交姓名/住址/银行卡号等个人信息给某个网站的时候，你应该知道你的信息会被任何包括员工在内有权限的人，以任意方式访问/传输/存储/使用/共享，并且你全都无法验证。
这就是为什么要在前端对密码加盐 hash ，使服务端对密码原文保持 zero knowledge 的原因。

事实证明，前端 hash 依然解决不了安全问题，绝对安全还是得上 2FA

@zhangjiashu2023 #75 看到了，谢谢

@Jirajine 等等，谁光跟你说提交了？中间件不光能输出请求体，也能输出 response body 的啊大哥？你的敏感个人信息也是会包含在诸如卡号、姓名、令牌、关联令牌等这些 api 的返回信息里的啊。
lz 你既然这么担心中间件作妖输出提交的信息，那么为什么也不担心一下中间件会同样输出 response body 里的敏感信息？你的顾虑是有道理的，但问题在于我十分不理解为什么你只顾虑密码。按照你的逻辑考虑到这种地步的话，不光请求体里的信息必须加密，所有 api 的 response body 也是必须都要加密的。
而结合 lz 你的帖子和发言，我觉的 lz 你单纯就是经验少连我说的这层都没想到