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

## 假设

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


## 1. 明文请求登录和存储

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

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

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

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

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

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

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


## 总结

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

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

PBKDF2 - PBKDF2 演示封装 - 水水的演示站
https://demo.wdssmq.com/tools/PBKDF2/

之前 v 友说如果确实要弄可以用这个方案。。

如果基于 Kerckhoffs's principle ，那么不能依赖客户端的服务器不被攻破，所以方案 3 和 4 是一样的。
搜索到 https://crackstation.net/hashing-security.htm ，这篇文章说得非常好，建议得方案比 OP 第 4 种稍作了一些变化，前端的 hash 函数使用标准密码哈希函数（例如 Argon2 、bcrypt 、scrypt 或 PBKDF2 ）而不是 SHA256 ，目的是减慢 hash 速度。

服务器被攻破了，别人在下载用户数据，你却在破译用户密码

4 感觉拿到 hash 后的密钥就能用 api 工具伪造请求，只是没有明文密码而已吧

在登入系统独立的情况下，密码可以由多个字段处理管理。
例如捆绑 ip ，换 ip 验证信息丢失。
验证器，例如谷歌等。
手机验证码，小金额保护。
人脸验证，大金额保护。

安全措施很多，不仅要只做密码一层。

这些逻辑都基于把密码当做用户隐私做安全措施，那用户隐私是什么级别的安全防护？当然明文存了。

@Tstxxy  😂，很多人都是这样想的。

楼主我再告诉你 2 个案例，有人说 cookie 不安全，别人登陆你电脑拿到 cookie 就可以登陆你淘宝。还有人说家里的门不安全，因为你钥匙掉了，或者被偷了就会被盗窃。

你提出的问题 跟上面没啥区别。目前市面 95%的 app （ web ）都不会通过客户端加密来请求登录的（当然做了是更好），微信和支付宝虽然我没研究过，但是花 5000 块钱 肯定是可以拿到你说的那些啥前端加密的方式😂 。

有安全级别比较高的 app ，比如支付宝，他们就需要你的人脸识别，短信验证等。

首先客户端的代码，花时间肯定能知道你的逻辑。
其次，服务器被攻破，花时间也肯定能知道服务器代码的逻辑。
因此，上面四种方案属于脱裤子放屁。

😰 没有讨论的价值，服务器都破了。拿着你最高权限都懒得管你加不加密了

我可能有点敏感，不过我写的小项目也是用的方法 4 ，防重放肯定是做不到，但至少可以让明文密码不离开用户机（你说用户机被攻破了.......那算了）