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

[drymonfidelia]

加盐 SHA512 这种方案反而我基本没见过
如果是为了检测是否是泄露的或者是弱密码，那可以把常用密码数据库同样加盐 SHA512 一次再保存（不过这样就要求 SHA512 的盐全部用户相同）或者把 1000 个常见密码发到客户端，在客户端判断
还有一种方案是 Scrypt KDF 以前在 discord 上看到有人讨论过，有实际应用案例吗

[2wex]

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

[abc612008]

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

[hyperbin]

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

[SethShi]

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

[yy306525121]

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

[codehz]

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

[xuanbg]

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

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

[Glkcv]

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

[xuanbg]

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

[wangtian2020]

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

[evill]

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

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

[selca]

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

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

[darkengine]

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

[Dragonish3600]

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

[superrichman]

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

[capric]

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

[yb2313]

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

[MIUIOS]

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

[bfdh]

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

[way2create]

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

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

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

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