求问：主流站点登录加密方式？

[acr0ss]

我想请教一下，现在业界都怎么处理登录密码传输呢？

我看主流网站，百度、京东、淘宝和 qq 等，都会把登录密码加密传输，而且参数很多，是有什么通用加密规则吗？


未防止不必要的跑题、炫耀等，我事先声明，我了解：
1. 对称非对称加密基本知识
2. 可逆非可逆摘要算法基本知识
3. HTTPS 基本知识，包含不限于数字签名、信任机构、信任链等。


我只想了解：
1. 为什么加密
2. 加密的主流通用规则

[acr0ss]

@xuanbg 如果多端登录，是否多端用相同的逻辑呢？

[acr0ss]

@westoy 个人认为还是需要明文密码的。要不然全站多来源登录，都得统一一个加密方式，而且加密之后、效力等同于数据库密码。

[GIntonic]

@xuanbg 谢谢 我傻了，我一开始理解成连账号都不需要传，直接在服务端确定登录的是哪个账号

[xuanbg]

@acr0ss 多端肯定要逻辑一致的呀

[S4m]

客户端用的大部分是 RSA，还有一些是 RSA+AES （有点像自己重写了 SSL ）

[janus77]

我个人觉得加密方式是不会统一和通用的，毕竟这是涉及安全的事，各家的考虑角度都不完全相同

[acr0ss]

@janus77 你这是太绝对。

HTTPS 使用统一的加密方式，
OAuth 授权流程大致相同
……

如果登录采用数字证书类似的公私钥加密，那是可以存在通用加密规则，而且服务端还能破译密文。

[acr0ss]

@xuanbg 请问贵司是这种方式吗？

个人认为还一点小问题。例如需要转发登录信息的场景。

[Veneris]

@xuanbg 我尝试复述一下逻辑。当用户尝试登录时候，首先通过 用户名 /手机号 等方式调用一个接口，该接口取出用户的密码，生成了随机的一个盐，加起来做 hash 运算，然后在 redis 中存储了{ hash(pwd+salt) : id }，然后把 salt 返回到了前端，此时前端将 用户输入的密码 +返回的盐 做一次同样的 hash 运算，然后再调用登录接口，如果此时根据前端计算的值，在 redis 中拿到了用户 id，即为登录成功，同时清除 redis 该键值对，否则，密码错误。您看，是这个逻辑吗？

[fishCulturer]

之前和公司老哥讨论过这个问题，当时讨论结果是防止内部人员作恶或者是提高内部人作恶成本
不止这个思路是否正确

[xuanbg]

@Veneris 是的

[EminemW]

我之前发现很多网站是传原文的。现在所有密码都是用密码生成器生成的

[YouLMAO]

加密为啥是服务端生成盐？直接客户端发送 1 版本号 2 盐 3 精盐加密后信息， 服务端对称解码，解出密码，按照数据库的真盐跟数据库精盐加密比对

[YouLMAO]

避免重放很简单，一般是对用户提交信息加上 session cookie，做一次 js 签名, 如果 session 都被偷了，只能加上来源 ip 了

[lap510200]

密码对外是加密后的明文 你说的是对客户端请求数据的加密吗 一般是让客户端根据请求数据按约定的加密方式生成签名 服务端验签，或者有的网关服务生成客户端指纹和数据包加密 验证在网关那就可以拦截

[Veneris]

@xuanbg 这样的话，我想了想可能会有些许的问题
1.因为每次都是与不同盐值做 hash，所以你们数据库是存了密码的明文吗，不考虑被脱裤或者内部人员作恶吗?
2.两个使用相同密码的人，随机到了同一个盐值，会导致获取到错误的 id，虽然几率小，但是是可能存在的，因为密码与盐值都不具备唯一性；
3.这种方式会有 hash 碰撞的可能，原则上不考虑，但比其他方式风险要高一点点；
感觉有些过度设计了。

[hehe12980]

@xuanbg 你这玩意不就是对称加密么 不过秘钥是后端给的

[hehe12980]

@YouLMAO 服务端生成 应该怕人爬到原始 js 代码 破解了

[YouLMAO]

@hehe12980 服务端生成随机盐的话, 服务端必须有明文密码呀, 这违反国际准则会被外交部谴责的

[hehe12980]

@YouLMAO 前端密码每次密码提交 md5 加密的结果不就行了 明文密码不做传输只做映射 基本的吧