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

@zhangjiashu2023 #78 明文本身也是存在问题的，hash 强于明文，hash+2FA 是强强联合，强强大于强，所以没必要因为有了 2FA 就用明文降级强度

@Jirajine 啊，对了。。。有一点差点绕进去导致我说漏了，lz 你再仔细想一想，当中间件真的输出了你的密码请求体，请问这时候输出明文密码还是 hash 加盐之后的密码有非常大区别吗？

按照 lz 的想法，需要在前端完成加盐 hash ，那么这个“盐”必须要存在网页或 js 代码里吧，那么对于一个都有能力去攻击你系统内部中间件的人来说，浏览器 F12 看一看你前端登录时用了什么“盐”是很难的事情吗？
这时候攻击者有了盐值，也有了中间件输出在 log 里的 hash 后的值，他要做的就只是跑一个彩虹表的事情。对于不复杂的密码这么做和明文是没区别的，该撞库你还是挡不住。而对于复杂密码的确彩虹表是跑不出来的，但一般非常复杂的密码往往都是随机生成的密码 or 用户根据自己一套规则生成的动态密码。你哪怕跑出来也没办法拿去撞库

再说一下，后端密码入库前必须加盐后再 hash 才会更安全这点，原因不在 hash 上，而在于 “盐是保密的” 这一点上。后端的盐除非出了致命漏洞被黑客侵入了服务器内部，一般来说是根本不会泄露的。因为“盐保密”所以这种做法才是安全的。而在前端加盐，这个盐是明文公布给所有用户的，也就是说加盐等于没加。

说实话，除了不想让服务端或这个服务商获取信息外需要再次在内容加密外，我真的看不出有必要，也就是端到端加密这种才需要再次对信息内容加密，


密码学本身对于大多数程序员实在太过遥远，这门专业的领域谷歌等大公司在具体业务方面有时候都能爆出问题，就不要说普通程序员的理解了。
有很多算法是根本不需要密码这种体系的，但是成本高实现起来也难，就说几个吧
1.基于身份的加密体系 IBE 可以做到不依赖公钥基础设施 PKI 来保证安全
2. 同态加密， 加密信息搜索以及各种之上的运算能达到明文的效果，可以确保隐私数据没有任何人能看到
3. 谷歌的零信任安全项目 beyondcorp 的系列论文

@FTLIKON
1. 创建账户/修改密码的时候，后端用一个全局固定盐 globalsalt 与用户口令拼接后使用摘要算法（ md5 ，sha 甚至 pbkdf 等等）入库为 pass1 ；
2. 登录的时候，后端生成随机盐 salt1 ，用户输入的口令与 globalsalt 拼接生成 pass1' ，然后拿 pass1' 与 salt1 拼接摘要生成 pass2
3. 后端收到 pass2 之后，取出 pass1 和 salt1 拼接生成 pass2' ，然后与 pass2 进行比较。

globalsalt 的目的是即便用户在不同网站输入的相同口令，也不会有相同的 pass1

@BeautifulSoap 你的论点完全偏题了。无论是密码也好，还是其他信息也罢，只要服务器知道的信息，那就都是一样的，没人关心你要怎么 secure 你的中间件。
They can do whatever they want with your data, and you have no way to know what they did. What else do you expect ?

至于“xxx 所以和明文没区别”这纯属滑坡谬误，假设我在 V2EX 的密码是`mypasswordforex.noerr.eu.org`，看到明文之后你能不能猜到我在其他网站的密码？更不用说很多人的密码文本本身就包含个人信息，如姓名拼音/生日等。

有同学说服务之间调用和日志会暴露信息，可以了解一下服务网格的零信任安全是怎么做的，现在欧美很多大厂要求微服务使用 mTLS 来保证通信安全。

关键要讲清楚，前端加密的目的是什么，要防止什么样的攻击/泄露。对于用户侧的攻击，找不要有意义的场景。对于服务侧，因为会有很多环节，加一层防止意外泄露还算有那么点道理。

前端用明文密码的最大阻碍，并不是 HTTPS 中间传输的安全性问题。而是后端拿到你明文密码后，公司内鬼会干一些什么。

尝试总结一下

用户端：
恶意软件/人员有很多手段获得密码，很难想象一种只有 HTTPS 内明文才能获得密码的场景。（安全的增益太细微）

中间人：
当前移动端安装根证书很难，PC 端需要权限。如果有本事装上，那同样有很多手段获得密码。
既然是中间人，那自然可以篡改网页，从你手里明文获得密码再加密发给网站，双方都无感知。（只有当中间人坏但又不完全坏时才有意义）

服务端：
服务端的安全性根本在于维护人员的水平。维护人员安全意识淡漠，到处都是漏洞，单单密码加密意义不大。
无论前端有无加密/散列，服务端数据入库都需要再做处理。只依赖前端加盐的安全性还是很有疑问。
在某些特定场景，例如网友说的内部人员打 log 出密码。如果是密文可能懒得研究，如果是明文可能会心生歹意。在这种
情况下，加密也许存在一定意义。

有时候，不要过度安全，很多所谓的安全措施其实是掩耳盗铃而已，比如登陆的时候前端先把密码 hash ，都 https 了，不要说什么中间人攻击，既然都能中间人攻击了，先 hash 难道有任何意义？

@ShuWei 增加复杂度有时也会降低安全

加密有多大用处？ 即使你再加密，你电脑不安全，记录你的密码，你也是百搭。 网站的策略默认你的环境是安全的。 你自己用 debug 不也是也能将密码搞出来，然后就演化成对抗了。

要么学学有些小方案，没有密码只使用验证码登录，直接校验手机和邮箱验证码。
是不是有人杠？ 有个拿 q 逼着你登录？我怎么知道是不是有人拿 q 逼着你， 这样下去，所有人电脑都不安全，那成本岂不是会变大很多？ 登录首先向网站提交自己没有被 q 胁迫，再登录？

再举个例子， 文件系统， 磁盘不安全有坏道，那么文件系统是不是强制大家做双硬盘？ 你不是双硬盘我不要让你用？ 反正总有人说磁盘可能要坏，必须双硬盘，否则就是不安全。貌似两种观点都对，但是对于成本和用户体验来说哪个重要？脱裤子放屁的方案太多。

真是无语, Google 这几年强推 https 就是为了通信安全, 你还搁这"明文传输", 你用开发者工具看看所有主流网站的登录, 密码都是不会加密的.

如果 https 能被破解，那么你前端 hash 后传输也没什么鸟用，拿到你的 hash 还不照样黑你？如果 https 不能破解，我传明文又怎样，你还不是拿不到？

换句话讲，在传输过程中，数据安全是由 TLS 加密链接来保证的。当然了，在数据库存储时，必须加盐 hash 或采用其他可靠的加密手段，禁止明文。

不过，chrome 扩展拿到用户密码实在太简单了，而且请求发生在扩展后台里，平常在网页的开发者工具是看不到这个请求的，所以很难让人发现

两个问题：
1. 前端加盐后 HASH ，如果每个用户盐不同，盐存在哪？
2. 如何处理密码强度策略变化的问题，前端验证的话，更新前端代码吗？

我一般数据库设计用户表 password 和盐存两个字段，每个用户盐不同，前端原始密码 https 到在后台进行加盐后 HASH 存储到 password 字段，脱裤也没事。

@GODZZZZZ #96

密码怎么还会自己加盐 HASH 保存，怎么不用类似 bcrypt 去加密

@Jirajine so ，你的论点是什么？ 这里讨论的是中间件日志被攻击的场景，以及由此产生的安全隐患。lz 认为密码不能明文传输的最大论据之一就是这个。所以我结合自己的实际项目经历指出了 lz 论据根本站不住这个点，请问哪里偏题了？我的问题和质疑点还是没变，你都不信任中间件了为什么还只关心密码泄露这种小事？

是的，将密码明文存储，且不给注销。

已联系作者，上次调 api 的时候发现了，打算发个帖，这几天没空，就没发出来。