用户口令（密码）应该如何传输？要不要加密？ HTTPS 呢？举例分析

[FengMubai]

假设

口令在信道中传输时不会被窃取（就是未被安装伪造证书的 HTTPS ），但服务端被攻破

1. 明文请求登录和存储

攻击者得到了用户的口令明文，可以去其他站点尝试输入登录

2. 哈希请求登录和直接存储

攻击者得到了用户的口令哈希，可以构造请求去其他站点尝试登录

3. 哈希请求登录和加盐存储

攻击者在拿到服务端日志或执行权限时，可能获得口令哈希，然后构造请求去其他站点尝试登录

4. 加弱盐哈希请求登录和加强盐存储

例如，前端用SHA256($password + $hostname)请求登录，服务端用SHA256($hash + $salt)存储。 攻击者可能得到请求的哈希值，但因为加盐的存在，即便用户在其他站点使用相同口令，也无法重新计算哈希构造请求登录

总结

第 4 种方法是最安全的。当然我们作为用户，还是每个站点都使用独立口令最好

后记：刚拔完智齿，闲得无聊，把很久以前的思考整理成文

[processzzp]

SRP 可以了解一下，比你自己在那里闭门造车安全多了
https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol

[FengMubai]

@processzzp 你说的对。我想说的并不是如何实现，只是在 v 站有过很多次关于“HTTPS 还要不要加密口令”的讨论，我现在有了闲心跟进讨论

[aababc]

咋感觉少了一种情况，就是 明文请求，hash 存储

[v2tudnew]

用户肯定是希望站点安全保管账户信息......

[msg7086]

这话题好像每次都会变成吵架贴呢……

[FengMubai]

@aababc 和第 2 种实际上是一样的，因为假设信道是安全的，只是执行哈希计算的位置不同

[clf]

哈希加盐存储，明文请求

快进到不允许密码登录，只能验证码/扫码/第三方 oauth

[aababc]

再结合前两天看到的，密码门锁的 虚位密码 感觉又是另一种情形了！

[Puteulanus]

既然服务端已经被攻破，那你怎么防止攻击者直接修改你的前端代码来从用户手里获取明文密码呢

[FengMubai]

@Puteulanus 说得好，但不影响第 4 种方法是这 4 种里最安全的

[henyi2211]

Challenge - Response 模式，连密码都不用传

[jinliming2]

HTTPS 下面传明文就足够，其他轮子意义都不大。
在不破坏 HTTPS 的情况下，明文不会有问题。
在 HTTPS 被破坏了，比如中间人，或者 HTTPS 用了过时不安全的算法，那么：
传 HASH：直接截取重放即可。
传带时间戳的 HASH：要求服务端明文存储用户密码。
用加密算法加密：不管对称还是不对称，都需要给客户端下发加密密钥，HTTPS 被破坏的情况下，中间人可以替换下发的密钥，做代理。
客户端预置密钥/公钥：你重新实现了 TLS 。

[GeekGao]

Okta API 传的是明文，我想世界上没有第二家比之规模更大的身份管理厂商了吧。

[murmur]

base64+https 就可以了，https 都被劫持了你的 js 文件是不是真的都是两回事，base64 完全是为了对付等保

上次有个等保扫我们，说我们所有的 api 路径都用了明文，无语，还专门写了个代码把所有的接口地址都改成\xx\xx\xx\xx 这样的写法

[FengMubai]

@jinliming2 你说的对，但是你完全忽视了我的假设

[wOuv7i4e7XxsSOR1]

不知道你在说什么，就算攻击者得到用户的口令哈希，他怎么去构造请求登录其它站点？你该不会以前口令哈希是前端请求的时候构造的吧？

[wOuv7i4e7XxsSOR1]

不知道你在说什么，就算攻击者得到用户的口令哈希，他怎么去构造请求登录其它站点？你该不会以为口令哈希是前端请求的时候构造的吧？

[wOuv7i4e7XxsSOR1]

还有你这第四种，“前端用 SHA256($password + $hostname)请求登录，服务端用 SHA256($hash + $salt)存储”，你要不好好看看你在说什么？

[Nosub]

和 op 主几乎一样的想法和实现，用的方法 4 ，

https://nosub.net/posts/p/104

[chinni]

我见过的一个网站就是 每次先请求一个 rsa pubkey 然后用户密码加密后传到后端 反正后端有 privkey 解密.. 存的话怎么存都行了 反正能比就好 很多成功例子