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

[mightybruce]

身份认证体系
1 、基于密码的认证
也称为基于知识的身份验证，基于密码的身份验证依赖于用户名和密码或 PIN 。密码是最常见的身份验证方法，任何登录过计算机的人都知道如何使用密码。

2 、双因素/多因素身份验证
双重身份验证(2FA)要求用户提供除密码之外的至少一个附加身份验证因素。MFA 需要两个或多个因素。其他因素可以是本文提及的其他身份验证类型或通过文本或电子邮件发送给用户的一次性密码。“多因素”的涵义还包括带外身份验证，其中涉及第二个因素与原始设备位于不同的通道上，以减轻中间人攻击。这种身份验证类型增强了帐户的安全性，因为攻击者需要的不仅仅是访问凭据。

3 、生物特征认证
生物识别技术使用用户自身生物特征进行验证，较少依赖容易被盗的秘密（例如密码口令）来验证用户是否确实拥有帐户。生物识别身份也是唯一的，这使得破解帐户变得更加困难。

4 、单点登录
单点登录(SSO)使员工能够使用一组凭据访问多个应用程序或网站。用户拥有身份提供者(IdP)的帐户，该身份提供者是应用程序（服务提供者）的可信来源。服务提供商不保存密码。IdP 通过用户通过它验证的 cookie 或令牌告诉站点或应用程序。

5.基于令牌的认证
令牌身份验证使用户能够使用物理设备（例如智能手机、安全密钥或智能卡）登录帐户。它可以用作 MFA 的一部分或提供无密码体验。使用基于令牌的身份验证，用户在预定的时间段内验证一次凭据，以减少持续登录。

6. 基于证书的认证
证书身份验证使用证书颁发机构颁发的数字证书和公钥加密来验证用户身份。证书存储身份信息和公钥，而用户拥有虚拟存储的私钥。

在一些登录系统需要提供提供预先协商好生成的 x.509 证书就是

流行的身份验证方法协议

Kerberos

OpenID

LDAP

[mightybruce]

历史上这种自作聪明在安全体系里面加这些还有自我设计安全协议的，都是非常非常可笑的。

密码学和网络安全协议设计是非常非常严谨的学科， 协议每一步都需要经得住逻辑验证，甚至有了专门的形式化验证工具比如 BAN logic 。在下面链接里介绍一下长达几十年没有发现逻辑问题的协议 Needham-Schroeder 协议和后续修复，因为这个分析实在太长了，很多人也不会看

https://codelife.me/blog/2013/06/13/needham-schroeder-protocol/


建议详细读一下这本不错的安全著作，不要自作聪明，画蛇添足。
Protocols for Authentication and Key Establishment
Book by Anish Mathuria and Colin Boyd

[mightybruce]

在安全信道中有没有再次加密的必要，除非是要求极致安全，不在乎通信效率的传输比如军事上，其建议的是端到端加密，
也是在安全信道中在开始连接中再次建立起双方的安全信任凭证。这个一些邮件和聊天中都需要手动开启。

中间人攻击对基于 PKI 体系的 TLS 是无效的

那么更复杂和安全的加密认证体系由于计算和实现比如基于身份加密（ IBE) 的方案，使用的是双线性映射（ bilinear pairing) 学术界搞了十几年，工业界落地的都没几个。
最近 10 年搞的格密码，基于格的 Identity-based Encryption （身份加密）倒是有可能落地。

[ShinichiYao]

https 下明文传输不要紧，重点是不要明文储存(包括日志里)

[kyuuseiryuu]

针对第二条附言，因为他们增加用户绕过他们的客户端的难度是为了防止自己的业务不被恶意利用，。

[macaodoll]

非明文传输是为了反爬虫。

[Rehtt]

我认为 https+url 密码明文不安全的一个地方是日志记录，比如 nginx 会将访问的 url 写入日志里，如果密码在 query 里那会被写入日志

[790002517zzy]

画蛇添足...逻辑都没通，前端永远是公开的代码，再怎么处理别人也能获取到加密方式

[guo4224]

好重的戾气

[killerv]

- 安全是分级的，更高的安全性当然会带来更安全的保障，但不是没有代价的
- https 明文传输一般没什么问题，加密传输一般是为了防止内部泄露（服务端记录登录日志、用户网络甚至终端被入侵），这是更高级别的
----------
别说 https 下数据加密传输了，国内大厂的全站 https 当年都落后很多……

[Jack927]

曾经我也认为，上了 https ，就没必要在数据上在加密。
但是现在，我认为，有需要的情况下，得加，而且不局限于密码，任何传输的敏感数据都可以且有必要加

[solos]

可能楼主需要的是密码管理器 你用随机密码就好了 随机密码相当于加密了🐶

[zhenjiachen]

小公司前端加密确实不需要，他们这些大厂加密是因为可以防止大量爬虫和撞库，他们有技术和能力对抗前端代码的反编译，小公司没这个能力，简单的写个 aes 加密直接就反编译出来了，还不如直接使用明文传输，密码保存在数据库使用 bcrypt 算法来做 hash ，这种算法一定程度上防止了被脱裤爆破出用户密码。

[nothingistrue]

楼主就是典型的这类人：要求 Windows 密码 20 位+有特殊字符+一个月一换+一年内不能重复，然后导致密码被直接贴到了显示器上。

[LuckyLauncher]

"再扩展个例子，比如你正在输入密码，就差点击确认刚好有人借用，你给他用了，他登陆了打开了调试获取到了，或者你有抓包软件运行，别人使用你电脑时候获取到了，这些都不是信道本身中间人相关的问题。"

- 我都用你电脑了，我直接通过控制台获取密码输入框控件的值不好吗？用户输入的总是明文的了吧？


“简单粗暴点从实践出发, 我就想咨询下各位坚持明文的兄弟: 为什么 Amazon Web 不用明文? 为什么淘宝 Web 不用明文? 为什么 telegram whatsapp 网页版不用明文而是其他设备扫码登陆?”

- 电商领域有没有可能考虑的不是安全性而是反爬机制，你看看他们的风控就知道了，以前淘宝的风控被诟病成人类都无法使用。当然这只是我的猜测，至于厂商为什么选择加密只有他们做加密的人知道了，可能亚马逊和淘宝选择加密的理由还不一样。

[cheng6563]

HTTPS 是砌一堵高墙，不攻破 TLS 就翻不过去。自己再套一层加密因为没法处理根证书信任之类的问题，相当于往路上丢快砖把人绊倒。你说有没有用那肯定比没有好，但你说有多少用吗抬个膝盖就能跨过去

[Bingchunmoli]

没有人考虑过因为大部分网站没有 hsts 导致降级攻击吗

[slack]

楼主你最好搞清楚你要防的是什么人，了解一下什么是威胁模型，你这样做无异于画蛇添足。

[Felldeadbird]

讨论安全前，建议加一个前置条件：公司规模。
人少的企业，没专业的运维，专业的安全团队，别折腾了，搞这么复杂推屎山。

特别是没有安全团队的公司，你认为的方法在安全人员眼里就是玩泥巴，一捏就散了。不然为什么搞安全的人工资这么高。

[flyqie]

思来想去。

貌似用法也就是在 server 和传输中看不到原始密码了。

剩下好像没什么作用?