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

[kabob]

今天登录某些网站时发现对密码进行了加密传输，这样做是防止哪些漏洞？

[fenghengzhi]

没加密：google 、twitter 、微软、苹果、github

加密：facebook 、amazon.com

[Puteulanus]

前端 hash 怎么加盐，在验证密码正确之前就得把盐传给他。。
攻击者不知道“明文密码”的前提是“别的网站都传的是明文密码”，如果所有网站都用的同一种 hash 方式的话，这个 hash 就是以前的明文，hash 这个操作只是网页上做的一种快捷输入。。就像用了 1password 之后可以说“明文密码”是 “command + enter”，但这个没意义，相对的所有网站的密码都是它输进去那个十几位的东西，那个才是明文密码

你不能既要推广一个标准，它的安全又是建立在其他人不用这个上的。。这就自己造密码学轮子的思维，像什么 md5(md5) 比 md5 更安全。。

[dingwen07]

@GuuJiang #25
你知道为什么要阻止“拖库后获取明文密码吗”。。。
Hash 等于明文这个结论到底是怎么得出来的

[g531956119]

@GuuJiang 这个问题底下最高票的答案，就是支持前端传 hash 并加盐的

[Felldeadbird]

在安全环境下，可以忽略。只是现实中使用场景很复杂。有精力可以前端加密一下。

[springz]

不一定，要看你这个 https 加在哪里，现在一般都有 CDN LB WAF 之类的，如果直接到到你后端服务没问题，但是如果 nginx 等等中间经过的层有日志之类的就存在泄漏用户明文密码的风险。最少前端 Hash 一下后端保存再加盐 Hash 一下。

[dongtingyue]

lz 想说的应该是自己用 rsa 加密下吧。直接到自己站点的没问题，套 cdn 有问题

[keyfunc]

@Buges 国内 CA 从业者来来解释下。就目前的规则来说，CA 是不可能配合做中间人攻击的，因为成本太高了。CT 的存在，热门网站的中间人太容易被发现了。只要有一次中间人的记录，基本上下年的审计你就别想过了。你可能认为审计会配合造假，但目前有资质做 webtrust 审计的都是 CPA 许可的，当年 CNNIC 的事件可是直接把 EY 的 webtrust 审计资格给取消了。再说了我朝一般的做法是直接搬走你的服务器，还用得着找 CA 配合你做中间人？

[dzdh]

前端加密没意义。

[newmlp]

@chenset 登录用 cdn 的意义在哪里？

[dzdh]

@keyfunc 最后总结精辟。考虑 CA 的隐患无异于杞人忧天。抛开现实空谈不知道有啥意义。

[dzdh]

@newmlp 隐藏源站 IP

[ytll21]

没有意义，因为如果不信任 https ，那么就代表不光是密码，其它业务数据都有可能泄漏。

那么怎么避免这种问题？最终方案只能是自己实现一个 https ，把全部的数据按照自己的协议来加密。

否则只加密密码，单纯只是增加了代码 kpi 而已。

[bdnet]

安全是相对的，账号安全目前普遍的做法：二步验证。更高级别硬件级密钥。

[zpf124]

@dingwen07
@g531956119
@Buges
你们说的东西和人家 @GuuJiang 说的是两个概念。
人家说的是 即便监听者拿到的是前端哈希后的值，那在当前网站依然被黑了，对于本站和明文传递没区别。A 网站的用户在 A 网站的密码还是暴露了，攻击者可以随意登录。

而你们在说攻击者拦截了流量会危害到使用相同账号密码的其他网站，A 网站用户泄露的密码会导致 BC 网站同样被可以攻击者登录。

我赞同你们说的存在的问题，但这个问题和人家提的点关联性不大，即便按你们说的加 hash 了，那人家提的 A 网站被攻破了的问题你们并没有扛住了，那为什么说的好像人家说错了一样。

[zpf124]

而且 https 被监听的问题我觉得不会如后端被脱裤那样容易引起大范围反应，https 要被攻击者解密我只知道让用户手动信任中间人的证书这一种情况。
除此之外我只听说过只有之前沃通还是那个 CA 的 bug 会给人发 gitpage.io 的根域名证书，然后这个 CA 就被浏览器火速拉黑了。

[zpf124]

@dingwen07
@g531956119
@Buges

我赞同 @GuuJiang 的观点，前端不要闲得没事自己做哈希，你们是准备把弱密码库之类的也写个 js 库自己前端做校验吗？然后弱密码策略也前端自己维护一份？比如什么密码包含生日包含连续数字包含账户名这种？

当然如果做加密我不反对，尤其是用非对称的，前端 js 里固定公钥就行，后端可以在注册和登录的时候照常反解回来，然后各种安全服务可以照常调用，弱密码相似密码也都不用前端处理，就是后端高并发的性能会差一些。

[zpf124]

当然 @GuuJiang 也理解错了一点他们的说法， 他们的说法是说 前端后端各做自己的哈希。
数据库存储的密码在他们的设计里是 后端:hash( 前端:hash(用户输入+前端固定 salt) + 每个用户个人 salt)。

这在后端眼里只是对于本站而言，等于脱了裤子放屁，用户密码由 123 变成了 a2cf ，但攻击者拿到的就是 a2cf ，拿到就能登录，对后端完全没区别。

[Buges]

@keyfunc 我倒不是觉得审计造假。事实上我相信目前的审计可以确保不会出现大范围的中间人攻击，如果国家有这个需要可以强制安装或让流氓软件偷偷安装自己的私有 CA 证书。我担心的是在完全可控的网络环境下针对特定目标的攻击。 至于搬服务器没啥意义，这里指的肯定是不受控制的目标。

[Buges]

@zpf124 你再仔细想想。拿到后端 hash 后的结果不等于拿到前端 hash 后的结果。
前端 hash 和后端 hash 是两个截然不同的安全层。前者的意义在于让后端不能接触到用户的明文密码，对用户的密码保持 zore knowledge 。而后者是阻止本站被脱裤后攻击者登录本站用户的账号。我上面主要强调第一点因为我觉得第一点更重要，因为本网站被拖总是有感知的，有感知就有办法补救。其他网站撞库才是最大的威胁。
而你们说的好像一但做了第一点就不能再做第二点了，事实上做不做第二点是另一个问题，与第一点没什么关系。
具体的例子可以去看看 bitwarden 的白皮书。