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

[acr0ss]

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

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


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


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

[chinvo]

@kop1989 #18 根本不防中间人, 中间人直接用加密后的结果或者登陆后的 cookie 就是了

防中间人只能用 TLS

[kop1989]

@chinvo #21 所以我并没有说能杜绝中间人攻击。而是“不能让中间人直接看到明文密码”。
另外，既然是“加密”而不是“编码”，那么必然 encode 之后的结果是一次性，且是时间相关的。

这些都能增加中间人操作的难度，而不是“杜绝”。

这就跟门锁一样。门锁对于锁匠而言都是玩具，那并不代表所有人就可以门户洞开。

[GIntonic]

我认为除了防止中间人得到明文密码，使用散列还可以证明服务器没有存储明文密码，被脱裤的适合减少危害性，毕竟明文泄露比散列泄露危害更大。
我理解的国内的各种加密、签名相当于在 https 里又实现了一遍 https，不知道对不对，希望大佬指正。我也很疑惑这似乎是国内特色，大多国外公司和开发者都没有在 https 内再加密，不知道有没有一个定论，到底是否有必要 https 内的数据再次加密。

[zwpaper]

@xuanbg 咨询一下，用 hash 作 key 的优势是什么呢？

[zwpaper]

@xuanbg 咨询一下，用 hsah 作 key 的优势是什么呢？

[crab]

@Mitt 国外大网站也多数加密的。

[xuanbg]

@zwpaper 就是防止中间人攻击而已。密码 hash 保密的原理就是利用服务器 /用户和中间人信息不对称。但由于有彩虹表的存在，所以需要加盐来保证不被破解出 hash 对应的明文。

[xuanbg]

@xuanbg 因为这个 hsah 是临时的，存在时间非常短暂，使用后立即失效，不使用也只会存在几秒钟。所以在一定程度上可以有效防范爆破。

[Veneris]

@xuanbg 这么做意义是什么，没理解什么场景需要用 密码加盐后的 hash 去找 用户 id

[Mitt]

@crab 据我所知，Apple Google Facebook Twitter 均没有二次加密

[h2xai111]

告诉你们一个秘密，ins 可以用来爆破用户密码，啥限制都没做那种

[unixeno]

历史遗留+反爬

[xuanbg]

@Veneris 没什么意义，就是登录时没有用户名，除了只有这个 hash，啥都没有。。。但对我来说信息已经足够了，我用这个 hash 能在 redis 里面找到用户 id，就表明暗号对上了，密码验证成功。

[xuanbg]

@Veneris 登录本质上就是客户端和服务器对暗号，我只是不直接用用户名 /密码对暗号，而是用一个临时的 hash 对暗号而已。

[qinxi]

还有一个防 log 啊,包括 cdn/nginx.
原本 cdn/nginx 运维不该有权限接触密码的.但是日志记录明文.那不就白瞎了

[acr0ss]

@codehz 非明文只要 md5 就行，何必大张旗鼓。是否明文我不关注，我只关注加密的方式是否又通用规则？

[GIntonic]

@xuanbg 请教一下 如果是密码加盐 hash 如何处理相同密码的问题，而且是否每次都要用不同的盐对所有密码做一次 hash ？最近也见到过登录只有一个 hash 的情况

[xuanbg]

@GIntonic 是的，盐是随机的。客户端要先用登录账号获取这个随机的盐。然后才能登录时只用传一个除了客户端和服务端，谁都不知道是啥的 hash 。中间人拿到这个 hash 只能一脸懵逼，尝试重放也没效果，因为这个 hash 是一次性的，当你抓到包的时候就已经失效了。

[xuanbg]

@GIntonic 啊，没仔细看。不是对所有用户的密码做一次 hash，而是对当前登录账号的密码加盐做一次 hash，然后也不需要保存到数据库，验证完就没用了。

[acr0ss]

@unixeno 反爬怎么理解？