启用了 https 的网站登录时密码加密有意义吗？

@Buges
强弱检查前端是比较好做，但是泄漏检查要只发送 hash 后的密码的话你还得把泄漏的密码也全部做一次加盐 hash ，是不是太浪费？

@liuhan907 浪费？你去看看那些泄露检测的网站，还有不少商业密码管理器自带的泄露检测功能，要是有哪个上传明文密码，赶紧去 hn 发帖把它批倒批臭。
再者说这种情况也不需要加盐，常规做法是 hash 后取一小段发送到检测接口，如果有命中则把命中项取回前端再比对。

@Buges
为了以防我记错了我又确认了一下，Twitter 和 GitHub 登录都是直接发送明文，我觉得似乎这两家也没被喷啊。

@liuhan907 这是普通网站登录啊，虽然直接发明文不是最佳安全实践但也不会被喷。但密码泄露检测是要你输入其他网站的密码，这种情况下上传明文就过分了。
标榜隐私加密的服务，如 1password 、protonmail 、mega 等，都不会发送明文。

@Buges
泄漏风险都一样啊，无非是检测的时候会上传更多密码。

@liuhan907 这与泄露没关系啊，我是 GitHub ，我上传你的 GitHub 密码这很正常。但如果我就一第三方，我上传你其他网站的密码，这是检测呢还是钓鱼呢，收集的数据是不是还要完善一波裤子。

@Buges
我是说

@Buges
刚才点错了…
我是说你最开始说的，HTTPS 下密码 hash 传输，意义不大。各大厂基本都是明文。

@liuhan907 hash 的意义我上面说过很多遍了。大厂传明文，说明大厂并不想对你的密码保持 zero knowledge ，很多用户的密码中可以提取出不少隐私信息。
而凡是以安全、隐私为卖点的服务商，和加密存储用户数据（并且宣称他们自己也无法解密），是不会让服务器接触用户主密码的。还有一个常见的例子是 Firefox sync 。https://hacks.mozilla.org/2018/11/firefox-sync-privacy/

@Buges

> 假如你密码足够随机”你是不是忘了还有其他用户的密码不够随机？
totally agree. 所以前端 hash 的作用仅仅是帮助减少密码泄露的风险面而已，对验证这个过程的安全性没有多大帮助。












------

> 如果前端不发送 hash 后的结果到后端，我如何证明自己无法解密用户的数据？

所以你有没有发现你试图用「 zero knowledge ENCRYPTION 」去论证传输一个 hashed password 是 auth 的必要条件 —— 但这根本不是用于登录的。


其实从你 #28 拿出这个来附会撞库和加盐就能感觉出你好像混淆了不少东西

1. 套上任意多的密码学机制当然会「更安全」，但不一定都有意义。这跟 hash 一次还是 hash10 次没区别是一个道理
2. 不接触用户数据的后端并不是典型场景，零信任 /零知识不是每个系统的必要条件，也不是登录 /身份验证机制的必要条件
3. 我存了用户的 salted-hashed-password ，也不可能拿出来去其它网站撞库。被撞站点的数据库公开且 hash 过程相同且密码原文相同，这是一个极其苛刻的条件
4. 不管前端是否先对 password 进行 hash ，数据库里的 password hash 反正都是「零知识」（不能还原出 password 到底是什么）的。对于用户来说，自己的密码已经必不可能由于机制缺陷泄露到第三方了，仅仅是第一方是否有权接触到密码这个问题而已，那这其实跟第一方是否有权访问用户个人信息是一回事，都已经是与登录无关的另一个层面了


-----

其实有一个问题可以用来自我检验到底有没有想清楚：「如果登录过程完全没有用户密码，仅使用个人证书，会比在 SSL 中传输同等长度的随机明文密码更安全吗」


答案是不会。

@GeruzoniAnsasu 所以加盐 hash 后，所有用户的“auth token”就都足够随机了。
hash 当然不是 auth 的必要条件，它与 auth 完全无关，但这并不等同于你所宣称的“无意义”。
hash 后再传用户可以确定你没存明文，传了之后用户就不知道你到底存没存了。
安全领域的一个典型原则：权限越少，攻击面越小。也许你你打算后端 hash 后再入库，但明文已经被存储记录在日志中了。

@zpf124 #55
本身数据库存储 Hash 而不是密码明文就是为了防止离线攻击的，对于防止自己的网站被攻破没有意义。
毕竟人家都拿到你数据库了，很多时候没必要正确用正常的登录接口访问数据了吧。

前端 Hash 的好处是可以证明用户的密码网站不知道，虽然我估计没有几个网站会这么做，也没有多大必要。

@Buges
日志里出现一个明文密码还是出现了一个 hash 过的密码，这个密码能不能用于突破登录只取决于日志的位置。「权限越少攻击面越小」非常对，可是把密码 hash 一下再传输根本没有减少任何权限。

拿你如此熟悉的 bitwarden 白皮书来说， 它用来什么手段减少第一方的权限？难道是 hash 一下 password 的功劳？
并不是，功劳是用户数据是加密的。加密用户数据才是减少权限的方法，它所做的所有这一切是保证加密是可信的。


你有没有想过

如果 HTTPS 不生效，这个系统的结果是啥


答案是，可以登录，但解密不了数据。



可以登录。

@GuuJiang @Buges @GeruzoniAnsasu

按个人理解简单总结一下当前的讨论情况：
1. 如果网站用户的期望是即便 A 网站被搞了（不管是被黑客入侵 /拖库，还是被内部开发 /测试或是其他人员非法利用，亦或是什么其它的方式），也不要影响到该用户在其它 B/C/D 网站的 [密码安全性] ，这种情况下，在前端就把密码进行 [hash] 处理对于该用户来说是 [有一定意义] 的。因为这种情况下，在后面的网络传输以及该网站后端拿不到用户的明文密码，不论是网站流量被解密监听还是该网站被黑了或是出现日志配置错误等问题，其它人正常情况下都很难还原出用户的明文密码（在不考虑超级彩虹表反向映射的情况下）。

但这么做（在前端就把密码进行 [hash] 处理）的好处，也基本上就这么多了——而且主要集中在那些会在密码中掺杂生日、名字拼音等隐私信息的用户上。如果不想让别人知道这些信息，最好的办法还是用密码管理器对各网站都生成并使用随机密码（虽然在实际使用上很难完全做到），一个是各网站密码不同，另一个是不暴露隐私信息。

如果网站被黑了，或是该网站后端有人通过日志等方式直接拿到了 hash 后的密码，他通过分析网站的登录接口最后还是可以进行登录并拿到用户的权限，对于该网站内用户权限的安全性并无实质性帮助。

2. 按 stackoverflow 以及本主题上面的回复来看，很多大网站并没有采用在前端对密码进行 hash 处理的方式，一方面是这样做对安全实质性的提升帮助不大，另一方面也是他们对用户的密码还有一定的企图心（也许真像上面回复中提到的“打算倒闭后拿用户密码再去其他网站撞一波库”）。

从安全角度来看，意义不大，过等保之类的合规性检查的意义更大

@GeruzoniAnsasu hash 以后让后端无法访问到（不需要的）明文密码，这就是减少的权限。
至于第二个问题，不 hash 密码的话用什么 key 加密才能保证只有用户能解密呢？

@dingwen07 现在说的是前端哈希，正常情况后端会自己做加密以及摘要，脱裤了攻击者拿到的也是无用的数据，你拿到前端的哈希那攻击者还能登录，但拿到数据库的密码字段是纯粹无用字段，除了 md5 和 sha1 其他方式攻击者都无法用彩虹表反解，连在本站登录都不能做到，如何危害其他网站安全？

而且这偏题了，提名是说 https ， 我的意思是 https 没那么容易被监听，所以前端不要自己做哈希， 你要是 http 那你爱怎么折腾怎么折腾去，我虽然依然觉得前端哈希不如前端 RSA ，但好歹比裸奔强。