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

@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 。