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+明文就安全了，为啥还要有二次验证之类的额外的安全策略？

[body007]

v 站也有 2FA ，这是二次验证吧。

[lesismal]

> v 站也有 2FA ，这是二次验证吧。

@body007 #1 在哪里，我没发现。另外，即使有、也应该是强制用二次验证才算是安全上起到作用，不启用的话就仍然强度偏低。但是 v 站或者其他论坛这种产品类型的信息不涉及资产之类的，所以还好，用户多站共用相同密码问题更大。

github 我不知道现在是不是必须使用二次验证了，好像也是最近哪一年才开始推二次验证的吧

[lesismal]

@body007 看到 2FA 了，谢谢

[FengMubai]

我放弃说服哈希更安全了. 换个思路, 我想说, 密码(口令)明文是隐私, 不应该让服务端知道的隐私

[FengMubai]

@FengMubai "你"知道我的密码明文, 也知道我的用户名, 我可以认为"你"有能力去其他网站尝试登录我的账号

[hefish]

现成的 DH 交换算法，面试前大家都复习过吧。 实际应用的时候，就偷懒了。。。共享密钥必须是算出来的才算安全，直接传输的，不都得降一级嘛。。。

[cndenis]

安全有一个原则叫纵深防御, 就是当一个防护被突破后, 有另一层防护, 会更安全.

就好比说数据库已经有密码保护了, 为啥不能往数据库里存用户口令明文呢?

同意#5 的看法, 口令 Hash 可以避免受到中间人攻击时, 口令明文被用于在别的网站上做碰撞

[ZE3kr]

> 密码(口令)明文是隐私, 不应该让服务端知道的隐私

同理，私聊的消息是隐私，因此不应该被微信服务器知道

[cmdOptionKana]

只能明文传密码吧？

你的建议是什么？哈希？哈希后传给后端，那么密码就是这个哈希值啊，想做坏事的人拿到这个哈希值可以直接走 api 发给后端，这与明文有啥区别？

[Al0rid4l]

这主要取决于你要防范的对象是谁, 防的就是用户, 那就加密

这么多安全策略, 但是每个都有针对的对象和场景

[cmdOptionKana]

另外，对于注重安全的用户来说，只能默认厂家知道明文密码！

对于注重安全的用户来说，每个网站的密码都是不一样的，都是随机生成的，根本不怕厂家知道明文密码。

而对于“不”注重安全的用户来说，你说的这些又有什么意义呢？人家根本不 care 。

[Wy4q3489O1z996QO]

单纯的认为即使有 https 多加一次密又不费事，为什么不把明文加密一下呢

[ZE3kr]

首先用了 HTTPS 就不是明文传输密码了。标题本身就是伪命题

其次

1. HTTPS+密码 不安全
2. HTTPS+前端加密的密码 跟 1 一样不安全
3. HTTPS+密码+TOTP 跟 1 和 2 比更安全点
4. HTTPS+Passkey/Biometric 最安全

老网站用 1 是历史遗留问题，1 升级到 2 必然是有成本的，不如直接升级到 3 和 4 。

[Curtion]

农业银行对接支付的接口也是明文的，只是会有证书验签来保证安全。 只能说加密传输有好处，但是没有那么大，还会增加额外开发成本，如果真的有安全上要求也可以用其它方案来解决，例如 2FA 什么的。

[wolfie]

加风控呗，新设备登录要求 手机或邮箱验证码，再上一层要求密保问题。
默认拿到手机邮箱的就是本人。

[Jirajine]

你应该把标题改成“服务端能够得知密码原文”。
使用了 https ，其实就已经不是明文而是是加密传输了，在这之上再进行额外多少层的对称还是非对称加密，只要服务端有能力解密得知密码原文，那就都是一回事。
前端进行 hash 的目的只有一个：让后端对密码原文保持 zero knowledge ，其他的安全策略于此是正交的。

[LnTrx]

个人看下来：
对于用户侧，如果恶意软件/人士已经掌握足够权限，那再 HTTPS 内再加密也没意义。关键是要找到一种场景，HTTPS 内再加密能防住、HTTPS 防不住，且这种场景有考虑的价值。我暂时没还想到。
对于服务侧，经手数据的很多环节都是能看到 HTTPS 内明文的。最典型的就是内容分发，通常 CDN 的本质就是可信中间人。如果数据流转的环节需要再加强防御，那 HTTPS 内再加密还有点意义，据要结合具体场景分析。就拿 CDN 举例，如果 CDN 是坏人，只加密密码，用户隐私、Token 等信息都是明文，那一样可以窃取信息、拿下账户、伪造信息，那加密的意义也就不是很明显。

[mightybruce]

赞同 ZE3kr 所说， 是这么回事。

这个问题要展开可以看看知乎密码学博士的回答吧
https://www.zhihu.com/question/20306241

[0o0O0o0O0o]

> 例如有人借用你电脑的时候给你设置了个代理或者装了马

威胁如果来自客户端，那我觉得目前提到的所有措施都没办法保证安全，我建议讨论的时候默认客户端是安全的

至于常见争辩的密码加密传输还是明文传输还是前端传个哈希。。。或许可以搜索关键词 PAKE ZKPP

[night98]

要讨论的地方就三个点
1.客户端安全 就你举的例子，我直接监听输入不就得了，你就是在 html 页面写出花来我监听键盘输入就搞定了，证书之类的纯属多余。
2.传输层安全 除非你使用的是非正式的证书或 CA 机构不可信导致传输过程被破解，这个有可能，但概率极小，而且一般来说价值不匹配
3.服务端安全 现在基本上都标配 Bcrypt 了吧，很少有直接明文存密码的。如果非要说网关层有泄露的风险，那我只能说你别扯了，有这功夫我插入个 js 脚本到返回的 html 页面中都比你入侵网关去查某一个接口的请求响应拿到的东西更多。

你要真保证绝对安全， 就用硬件来保证，至少比纯密码方案靠谱几倍，直接分发硬件加密码的方式，每次登录硬件生成随机密码来登录，比你折腾那玩意靠谱多了。