登录接口明文密码在浏览器端先加盐 SHA512 一次，服务端再用 bcrypt 等慢哈希算法二次加密存储是最佳实践吗？为什么多个大厂都发生过不小心在日志输出用户明文密码的事件，不加密或可逆加密传输用户密码仍是主流

互联网企业搞安全成本高收益小，除非监管强制要求，否则能省就省

没法判断密码是否符合复杂度要求吧，大小写特殊符号之类的

因就算泄露了没人追责，也没有天价罚款，所以无人在乎

你说得对，bcrypt 能解决密码问题，但是你架不住历史包袱久，重构账户相关出事了一锅端
只要不重构禁不住有人打印整个模型，模型有自带解密方法
至于你说的检测规则，都已经加密传输了，直接从前端检测就好了，还检验什么前端搞坑多
所以还是后端哈希，片段 HTTPS 就行了，至于密码的事，后端的问题自己解决，工程化的工程化，不然下次没课密码，还有身份证，手机号

我们都是直接对称加密或者非对称加密，到后端再解密

零知识证明不就可以了？比如 telegram 用的 srp 协议和更通用的 pake 协议，只要保证客户端没人篡改，就没人可以解密原始密码，服务器也不知道

服务器本来就不应该知道用户的密码是什么。严格来说，就是明文密码不出客户端。只要这个密码离开客户端，就要用摘要算法计算 hash 值代替。

另外，加密传密码是什么鬼？你拿用户的密码想干什么？

@xuanbg 只传摘要，那设置密码也穿摘要吗

@Lexgni 当然啦，通过别的方式而非密码验证用户身份的合法性，譬如短信验证码。

你是老板还是打工的，加密差不多够用就得了

不是这种方式有什么难度，也不是这样做有什么成本

而是做的某种程度(特别是 toC)有人会要你明文保存，但是没文件没规定
最搞笑的是这个和等保还是冲突的

前端判断强度就完事儿，你硬要用接口突破安全行为，设置弱密码，我这儿也看不到密码原文。

实在要全链路安全，还得设计类似 tls 的公私钥握手过程。

先问是不是，有哪些“多个大厂都发生过不小心在日志输出用户明文密码的事件”？

前端加密本身就是脱裤子放屁的事，都有 https 了前端加密的意义是什么

@ladypxy https 是防传输过程泄密，前端哈希可以防止在传输目的地的服务端泄密，两者并不冲突。

用 opaque
https://github.com/facebook/opaque-ke

为什么要在前端加盐, 如果会被截取, 人家直接拿加盐后的密码当密码用不就行了吗? 如果不会被截取, 那直接明文传输在后端加盐哈希存储才对吧?

《大厂都发生过不小心在日志输出用户明文密码的事件》
没听说，至少我不会把用户登录信息输出到 log 上，没啥意义也不必这么做

@xuanbg #7 "加密传密码是什么鬼？你拿用户的密码想干什么？"
1 、客户需求，而且这个客户还不听劝；
2 、有些软件就是需要明文密码，比如 pppoe-server 、svn server 、ftp server ，虽然有些可以结合其他软件使用非明文密码，但简单实现都是基于明文的。

不前端加密 新项目都是直接 https+bcrypt 旧项目懒得管 他们怎么写我用啥 不操心这些

如果还需要加强安全措施不都是二次验证之类的

至于前端加密，B 站那些卖课的就喜欢搞这些

另外如果一个项目日志会泄露这些。。。那估计我想就不单单是密码的问题了

我有个项目就是的在前端加盐 hash 后给后端的，密码强度验证就只在前端，后端只收到 hash 结果。

前端加密也好，hash 也好，作用是什么？完全没看懂。

我只能想到一个作用，就是拿这个特定的用户名和密码组合来做碰撞攻击其他服务/工具。

服务器端有一百种方式泄露用户密码, 例如 nginx 日志, 网关层, 框架日志, 接口请求记录, 中间各层 HTTP 请求,RPC 请求 ... 不管怎么样, 从服务器接收到请求开始,再到用户中心给密码加密之前, 所有中间层能可以明文看到用户密码 .

没明白前端 hash 的意义在哪，对与服务端而言密码不就变成了前端 hash 后的值了吗？非但没有提升安全性，反而增加了碰撞的可能性。

1. 谈不上最佳实践，bcrypt 加密没啥争议，java 的主流做法。至于浏览器端加密，满足客户要求就好，最多的场景就是浏览器提交的密码不是明文就行。浏览器端加密本身争议就比较大，没必要非得求个定论。2. 密码泄漏我有印象的，一个是 csdn 被拖库，因为用明文存储的，另外一个是阿里云的事情，细节不记得了，原因是把 secretkey 写到了代码里，然后传到了 github 上。没听说过日志泄漏的。这种只能说开发也太没有安全意识了，敏感信息不该进日志。

@shenjinpeng 都能进入中间层了，明文密文还有意义吗？反正后端认就能利用。

第一 https 都被挟持了你做再多的加密都没用了
第二密码可以携带多重信息的，比如可以在密码后面加验证码可以让老版本没有验证框的也能登陆

其实没意义. 前端明文 + https + bcrypt 即可. 至于 https 被劫持和 后端流程泄漏密码, 这是另外的问题.

有很多人说前端 hash 是为了防止服务器沦陷，比如服务器流量干脆被劫持，TLS 证书被盗。
“服务端不可信任！”
但是如果是 web 的话，入站流量里的密码能被劫持所以你 hash 了用户密码，思路 OK 。
但是如果服务器已经沦陷，别人不能直接改你出站流量里前端 js 脚本吗？直接去掉 js 里 hash 步骤让用户明文提交，或者干脆就钓鱼，咋办？
或许你做的是 APP 的 API 吧，不从服务器接收认证逻辑，我不否认这是一种纵深防御思想...

我对此的态度是，反正没有太大收益，只要不怎么增加复杂性，开心就好。

因为信任 TLS ，信任服务端。我想这就是不 hash 提交密码的原因。
否则服务端若不可信任，你大概要再做一套认证+加密，几乎就是再发明一个 TLS 了。

所以我也不太清楚，TLS 后，前端流量还要加密一下的意义有多大，我见过有用 AES 的(对，还不是非对称)，甚至比前端 TLS+hash 还难理解它的意义。

不恰当的比喻：TLS 都能被攻破的情况下，你再加一层凯撒位移不会更安全。
制造无意义的信任边界，过度设计只会让事情变得复杂，增加成本，甚至可能更不安全。

btw ，什么是“可逆加密”？不可逆的加密是加密吗？（小声）

明文密码不一定是泄漏，还可能是试出来的。

我们会对敏感数据做非对称加密再传输

Google 登录至今还是传输的明文密码，Twitter 也发生过明文密码记录到 log 的安全事故。所以明文传输密码本身并没有什么问题，只要后续链路存储规范即可。

@superrichman 你服务器都能泄密了，你啥加密都没意义了

@yb2313 盐即使泄露，问题通常也不大。盐的主要目标是防止相同密码产生相同哈希，以及抵御彩虹表攻击。只要每个用户、每条记录的盐都不同，这样即使攻击者拿到所有盐和哈希，也不能用一个统一的预计算表（彩虹表）去快速破解。

@ladypxy 服务器泄密，接收的和存储的是哈希过的信息，不会泄露原始信息，怎么会没有意义。

加密/哈希的意义就是“把泄露变得不等于彻底泄露”，降低风险，增加攻击者成本。

楼上那么多人连 hash 不是加密都不知道，笑不活了。

难得 LZ 那么有责任心来问一下，结果钓出那么多卧龙凤雏。

明文密码泄漏，是怕你用密码拿去尝试登陆别的网站，不只是泄漏密码的这一家网站的事情。

用密码管理器的表示没关系，你安全做的不好泄漏也影响不到我其它网站

这个问题叫 ZKPP （ zero-knowledge password proof ），已经有非常成熟的方案例如楼上提到的 SRP ，PAKE 。
码农不要自己用半吊子的密码学知识拍脑袋想方案，真要安全就用已经标准化的 scheme 。
不过互联网企业大部分属于是能 hash 一下已经是业界领先的水平。

我怎么没看懂这是在说啥哦

@superrichman 服务器泄密，接收的和存储的是哈希过的信息。你服务器登录啥的用的都是哈希过的信息了，不是院士信息，那你这些信息泄漏了别人完全可以伪造登录了。那你的意义在哪里？

@yulon 没什么别的意思 单纯好奇一下 你说的楼上那么多人是谁呢 我咋没看到有很多 求科普
除了一个说 bcrypt 加密的 很多 v 友提到加密不都是针对 op 最后一句话问的“为什么不加密传输仍是主流”回的吗

@ladypxy 哈希的意义在于保护原始密码，从而避免更大范围的损失。保护了用户在其他平台上的安全，不至于“一处泄露，处处沦陷”。

如果服务器直接保存明文密码，一旦泄露，攻击者不仅能直接登录这个系统，还能尝试用相同的密码去撞库或者了解你的密码设置习惯，攻击你的邮箱、社交媒体、支付账户等更高价值的服务。

而保存的是哈希值时，攻击者手里拿到的并不是密码本身，而是需要通过暴力破解手段反推，成本和难度大大提高。

@ZhiyuanLin 确实，hash 一下业界领先、加盐业界前沿、会用密码哈希已经是行业领军了

相比于密码在 https 传输过程或者后端日志泄漏带来的风险，普通用户使用弱密码的风险更大，所以还是针对弱密码做后端校验吧。

webcrypto pbkdf2

@ZhiyuanLin 密码学, 很神奇吧, 只要两次通信就能实现一个十分甚至九分的安全密码验证

我在 6 年前抓过国际大厂的登录接口，都是明文传输密码的，现在抓谷歌的登录接口也是明文的。

行业已经有最佳实践了，别闭门造车了
OPAQUE: The Best Passwords Never Leave your Device

https://blog.cloudflare.com/opaque-oblivious-passwords/


月经问题了

有些场合要求服务端必须能拿到口令明文。

十多年了，做的严肃项目都是前端 md5 ，后端每用户一个 salt 再次 hash 。
推广 https 后，前端密码都明文传输了……

中间人攻击都要防……活着太累了！都接入 Authenticator 算了。

@liuidetmks #45
> 行业已经有最佳实践了，别闭门造车了
> OPAQUE: The Best Passwords Never Leave your Device

当前最佳实践其实应该是 Passkey ，不用用户记住密码了，连 identifier 都一起搞定了。
而且除了 session hijack 几乎完全没有盗号可能性。

@ZhiyuanLin 先不说多少人能用 passkey ，用 passkey 作为唯一登录方式的话，你的客服邮箱一定会被一堆换了手机登录不进账号的邮件塞爆

现在还需要密码吗？基本上都是短信或者微信的事情了。

保存可解密的密码本身就不是一个靠谱的方案,应该在用户输入密码,提交的时候使用哈希算法计算密码哈希值,提交的不是明文密码,后端再对密码哈希值进行加盐哈希存储,这样服务器没人知道用户明文密码是啥,哪怕有内鬼也不行,唯一的风险就是前端如果没有加盐,哈希计算后的密码被劫持后有可能通过撞库推算出明文密码,当然这种方案是适用于账号登录相关,如果是交易密码,基本都是使用的非对称加解密

服务端就不应该拿到明文密码的呀

前端加密更多的是一种心理效应，领导看了舒服，也不能说卵用没有，聊胜于无吧

后端加后 hash 就好，要讲究安全应该上 2FA 。