HTTPS 用明文传输密码的问题，看到很多次了，个人观点不赞成，单开个帖

[lesismal]

在隔壁 #71 #74 回复过了，但估计很难被人看到，所以单开个帖： https://www.v2ex.com/t/1043320

github 的问题也不是没被暴出来过： https://zhuanlan.zhihu.com/p/36603247

单就传输信道而言，https 能解决中间人问题，明文在这个用户前端到厂商之间的 https 信道范围内没问题。 单就 github 而言，因为有二次验证，所以即使拿到密码了换个设备也登陆不上，所以有一定合理性。但 v 站没有二次验证，用明文我个人观点不太赞成

安全不只是传输信道，传输信道中间人之外还有社工、复杂的人生场景，例如有人借用你电脑的时候给你设置了个代理或者装了马拿到了你的帐号密码，以后说不定做什么坏事，这就属于传输信道之外的安全场景了。

用了 https 就明文只解决信道安全问题，用明文至少意味着：

1. 用户应该尽量管理好自己设备的安全
2. 用户到厂商之间的 https 信道之外的处理流程上，厂商应该确保安全，例如上面引用的文章里提到的 github 爆出来的问题

另外更简单的一个思考，如果不用明文、我们实现上增加了什么成本，带来了收益，有什么损失？

1. 成本：几乎没有增加额外成本
2. 收益：安全强度提高了
3. 损失：安全上没损失，但厂商不知道你明文，至于厂商知道你明文有什么好处，自己脑补吧

很多人都是觉得：有人用明文，尤其是有大站例如 github 用明文，所以就是对的，根本没考虑过信道之外的安全，也没有考虑大站是否有额外的安全策略例如二次验证，也没有去统计对比，是不是所有大站都用明文、或者用明文的大站占据绝大多数，也没有去区别不同站的类型和对安全的需求等级，比如是否涉及资金安全的，例如金融类、电商类相关的接口

再用脚想一想，如果 https+明文就安全了，为啥还要有二次验证之类的额外的安全策略？

[iseki]

不是，举个例子 LDAP 登录，这是很常见的需求。业务逻辑是尝试使用搜索到的 DN 和用户提供的口令 Bind ，Bind 成功即为认证成功，这就必须把用户输入的原始口令发送过去。

[lesismal]

@iseki LDAP 我没太了解过，但如果它需要明文的密码，这应该也是历史遗留问题，因为本质上是不需要明文的。另外，“必须把用户输入的原始口令发送过去”—— 这里的原始口令要看是哪种，如果是密码、那是历史实现问题和现在的兼容性、修改成本问题，如果是 OTP 这种单次验证码，则没关系，单次的验证码明文也可以、不怕泄露

[lesismal]

@lesismal #222 不要看它当前是什么方式，站在当前实现的方式的角度考虑问题则任何现状都有它局限于历史和版本等问题导致的合理性。应该撇开历史现状，看理论和实现方法上，哪种方式可以做到更好。是否把旧系统改造升级是项目自己的管理的问题

[iseki]

@lesismal 按这种讲法就没什么可讨论的了。一切当然是可以改的，就算是碰到必须获取原始口令的设施你也可以说改造旧设施，那还有什么可说的呢。

[lesismal]

@iseki
什么情况必须获取原始口令？密码和 OTP 是有区别的，你要说 OTP 我没意见。其他系统的密钥本身，我暂时想不到必须用原始明文口令的。
我的出发点是，实现各种密码存储需求本身要应对的业务，并不需要以来明文本身，历史问题是历史问题，但这里说的是方案本身的优劣，历史改造甚至都不在我考虑范围内
所以这根本不是说法的问题，是逻辑本身的问题，如果你一定要用“现在已经有哪些使用了明文、所以避免不了用明文”来讨论，那确实没什么可讨论的了，这不是我在讨论的问题

[iseki]

@iseki 从认证这个业务逻辑上当然不需要获取原始口令，也不该这么做

[littlez0325]

@csrocks 前端 hash 后传给你的是 hash 值,你还按之前的 md5(password+salt+password)摘要方式得到 md5(hash+salt+hash)的摘要值不就行了,并不是说把你的摘要算法放到前端去,然后你就不做了,前端可以用 sha1/sha256/PBKDF2 等等摘要算法计算摘要值,只要各个前端都统一加上就行,都是现成的摘要算法,接入根本就不需要什么成本,最大的成本还是项目刚启动时就都没有这个意识,后期改动会造成旧密码不能用,或者要加兼容逻辑

[littlez0325]

本质是防止原始密码被人知道,不用可逆加密算法,而是用不可逆摘要算法

直接把用户输入的密码按照一定的规则生成一个 salt(比如把密码的字符每 n 个字符删除一个,然后用 md5 或其他算法生成一个摘要值作为原始密码的 salt),然后 PBKDF2 算法生成一个摘要值传给服务端,服务端无法知道原始密码,也不需要知道,直接用传过来的摘要串做后面的逻辑(用加盐摘要算法生成摘要串落库/前面的方式对前端传过来的摘要串操作后和库里的对比是否密码正确)

1.密码强度验证逻辑没必要放在服务端,不会有人要对强制绕过前端逻辑直接传弱密码到服务端的用户负责吧
2.撞库不存在的,不会有服务端允许一个用户一直用错误密码尝试登录而不限制吧
3.数据库泄露的话,密码存的也是摘要值,完全可以每个用户一个不同的 salt(自定义的规则串,不用落库,比如用户的用户 id/创建时间等注册后就不变的字段按照一定的规则拼接,再加上一个服务端代码里的固定 salt 串,随你发挥,保证每次要校验用户密码时能拿到就行 salt 所需的信息就行),攻击者想碰撞就碰去吧