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

## 假设

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


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

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

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

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

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

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

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

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


## 总结

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

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

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

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

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

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

哈希加盐存储，明文请求

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

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

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

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

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