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

[kabob]

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

[Buges]

@PMR 恰恰相反，这才是“无罪推定”：即先假定该组织不会违反所在地法律。
其他 CA 组织，如果运营地法律有规定有配合 gov 做中间人攻击的义务的话，我觉得都是不应该采纳的。CA 采信的要求应该加一条：能够合法运营。就像如果开发一个 federated 端到端加密通信工具的话，不应该接受端到端加密不合法的地区运营的节点。
而不可信 CA 最有可能做的就是针对特定目标的攻击，审计只能保证安全（私钥不泄露），但却无法解决这种问题。

[crab]

Heartbleed 就能说明了

[jaylee4869]

如果你在一个给所有外部域名单独签发了私有 CA 证书的内网环境下，就有意义了。
我现在的公司就是这么做的。

[Tianao]

有的，ADC 从业者来答一下：很多 SSL offload 之后的流量会在数据中心内部长达数百米到数公里的物理链路中裸奔，而在很多共享 /托管数据中心，保护这些物理链路的只有象征性的机柜围笼、机柜门锁和柜列通道门禁。

[GuuJiang]

@Buges 前端 hash 是安全问题中最最最典型的一个只知其一不知其二而导致的误解，首先要知道之所以后端存储 hash ，目的是防止被脱裤后泄露密码，但是如果使用方式是前端 hash 并传输，那么脱裤者根本就不需要关心密码明文是什么，此时的 hash 就等于明文，使得后端存储 hash 变得形同虚设

[agagega]

某些情况下可以减少日志泄露密码的机会，但这不是一个可以值得依赖的安全实践：

- 没有 HTTPS 的情况下，攻击者从中拿到密码 hash ，依然可以进行重放
- 没有 HTTPS 的情况下，用户加载的一切脚本都可能被动手脚
- 如果 JavaScript 被禁用了怎么办？

[night98]

前端加密靠不住的，执行文件直接可查看，用 md5 或者 sha1 反而不安全(彩虹表暴力破解)，加盐也毫无意义，是固定盐的话照着再跑一遍仍然没用，非固定盐就又存在另外一个问题，盐从哪获取？

如果已知客户端不可信，那么任何手段都无法阻止用户的密码被泄露，这种就需要引入多因子认证，也就和密码加密没关系了。

https 解决的是 http 传输过程安全性的问题，想要解决客户端不可信的问题只能上硬件方案或者多因素认证，单靠密码是解决不了客户端信任问题的。

反而前端加密引入了更多的问题
1.服务端无法验证是否弱密码
2.服务端无法验证此密码是否已泄露(即其它脱库密码列表中)
3.服务端无法验证密码格式是否符合强密码要求

[Buges]

@GuuJiang hash 怎么会就等于明文呢，拿了 hash 你就能去其他网站撞库？再者别忘了还有加盐呢。
你要是不理解可以看看 bitwarden 的白皮书 https://bitwarden.com/images/resources/security-white-paper-download.pdf
我可以这样说，如果不能对用户的明文密码保持 zero knowledge ，这个网站大概是打算倒闭后拿用户密码再去其他网站撞一波库。

[Buges]

@night98 呃，你这更是暴论。验证是否弱密码不能在前端进行？至于是否已泄露，你去看看哪个查询密码泄露的网站需要提交明文密码的。

[GuuJiang]

@Buges 我从来没有否定存储 hash ，我否定的是前端 hash 并传输，你举的例子恰恰又一次证明了我的观点，如果全世界都前端 hash 并传输(假设在不加盐的前提下)，存储 hash 变得毫无意义

[Buges]

@GuuJiang 不知道你怎么得出的结论，hash 为什么不加盐？
好吧就算假设全世界厂商都失了智故意不加盐，那也远远强过传输明文。起码如果我密码是 xxxxx.v2ex 和 xxxxx.github 也不用担心泄露了被撞库。

[jsq2627]

有一点意义，但是意思不大。自己的密码传输搞得再安全，面对撞库也会很头疼。
所以现在的主流实践都是假定用户密码一定会泄露，靠 2FA 保证安全

[ysc3839]

@GuuJiang #25 前端进行 hash 运算后再传输不等于后端收到数据后原样保存。后端收到数据后，使用安全的 hash 算法运算后再保存到数据库，攻击者拿到数据库中的数据后，确实是不需要关心密码明文是什么，但仍要关心密码经过前端的 hash 运算后的结果是什么，为什么这会“使得后端存储 hash 变得形同虚设”呢？

[choury]

@ysc3839 #33 只需要把 hash 后的值当密码发送给后端就可以校验过了，并不需要知道源密码，因为后端也不能知道前端是否经过了 hash 这个步骤

[GuuJiang]

@Buges
@ysc3839
所以我说这个误解是多么的典型，因为会犯这个错误的人不少，类似的问题随便动动手就能搜到一大把
https://stackoverflow.com/questions/3391242/should-i-hash-the-password-before-sending-it-to-the-server-side
你一直在说撞库，请问防止撞库的手段是传输 hash 吗？不是，是存储 hash ，而传输 hash 的行为大大降低了存储 hash 的意义，极端情况下降为 0 ，你可以继续坚持自己的观点并在实际项目中使用前端 hash 并传输，但是麻烦告知下这样的项目地址以供避雷

[mikywei]

当然有了，因为你登录用户名密码用明文，直接就可以爆破你了。当然防止爆破也不止这一种方式，但加密也是很有效的，要爆破你还要猜你是怎么加密的，成本升高很多的，基本看到加密就不搞你了。

[EminemW]

@GuuJiang #35 要是后端把明文密码存起来呢。内鬼泄漏密码怎么防

[yeqizhang]

别说了，某些等保连个身份证都要求加密传输

[ysc3839]

@choury 但是攻击者还得知道原密码经前端 hash 后的值才行呀，攻击者拿到数据库后，只能知道原密码经前端 hash 后再经后端 hash 的值。
@GuuJiang 所以你的意思是，有很多人会直接把前端传来的值原样保存到数据库中？建议你明确说清楚，不然很容易让别人以为你不懂，以为你自己默认了“前段 hash 后传输=后端不作任何处理原样保存”。

[Buges]

@GuuJiang hash 之后还可以再次 hash ，不过我说的重点不是这个，而是将原始明文密码发送到后端的不可靠性。
脱裤后泄露最大的危害是撞库，某个网站自己被脱了他肯定有补救措施，比如强制两步验证、暂停登录等。但其他网站就不行了。只要加盐 hash 至少一次就可以确保 A 站脱的库无法威胁到 A 站以外的其他网站的用户帐户，这才是最关键的。
另外如果前端将明文密码发送到后端，那这个服务就是不可信的，你没法验证他到底有没有存储明文。除了内鬼泄露、脱裤被拿去撞库以外，很多不使用密码管理器的用户的明文密码中同时 encode 了如生日、名字拼音等隐私信息，可以在社工的时候提供相当的参考。