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

[lesismal]

@ZE3kr

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

兄弟你应该是没有仔细阅读我帖子的内容, 请先读完再说这观点

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

其实成本不高, 主要成本应该是两方面, 一是客户端方面的, 比如原生客户端升级空档期, 而是服务端方面的, 比如用户量巨大不能短时间内全部更新成 hash 盐, 需要停服维护或者新增表项. 服务端的代码修改相对简单, 例如明文和 hash 盐都判断, 两个失败才算失败, 然后更新数据也可以跑任务分批完成所以不影响性能和业务.

[lesismal]

> 但是却从来没考虑过，前端加密也好哈希也好，是有可能更不安全的

@icy37785 因为是跟明文做对比, 所以我认为你这个观点是指 前端加密哈希后可能比明文更不安全? 请教, 什么情况下会比明文更不安全? 因为我暂时想不到例子

[lesismal]

> 如无必要勿增实体

@pandaidea 这句话是对的. 安全场景不是"无必要"

[YangWaleed]

两篇帖子都看了，但感觉缺少一些信息导致感觉两边的讨论不太有效果。

我想知道 “前端加密或者哈希” 的完整方案是什么。前端进行密码处理后，后端服务怎么使用这个处理后的字符串，比如怎么验证正确和怎么存储到数据库。

在我看来，只有明确了完整的方案，才能和 “明文传输” 的方案进行比较。

[lysShub]

@cmdOptionKana 不存明文密码，即使数据库泄露也不能用于社工库，那些社工库就来自存明文被爆的数据库

[msg7086]

> 很多人还是没想明白，多加一步非明文成本没增加、几乎可以忽略，为什么不能多加这点
1.为什么成本没增加。
2.增加到什么程度才够？
就比如你说的多加一步加密没有成本，那为什么只加一步加密，为什么不加密两次，加密三次？为什么没有成本的加密只做一次。
如果加密多次也没问题，那么加密五轮就够了吗，还是五十轮呢，或者五百轮？

上面其实已经有人说了，用户侧加密其实并没有很大的意义，无非是用 5%的成本上升换取 5%的安全性上升罢了。你的帖子的问题就在于你缩小了增加的成本，放大了安全收益，以为这是一个用少量成本就能换取不少安全性的操作。但这种操作在真正学过安全的人眼里根本就不值一提。真正需要偷你鉴权信息的人，不会因为你加了一轮加密以后就偷不了了，而只是让他们多花半个小时把处理加密的行为加到他们的攻击代码里而已。在你为加密了密码传输沾沾自喜的时候，攻击者早就把代码改好了。

> 为什么 telegram whatsapp 网页版不用明文而是其他设备扫码登陆?
因为这才是正确的路线。放弃密码，不要用 what you know 而用 what you have 。

实际上我司（全国排名前五的软件公司）马上就要实施 passwordless 登录了，以后在公司登录账号只需要公司邮箱+手机 App 证书鉴权，不再需要记复杂的密码了。手机 App 则是指纹保护，每次鉴权时按一下指纹即可。
也就是说，邮箱+手机+我的手指，构成了鉴权。

[msg7086]

我看了看你引用的原贴，似乎是浏览器插件读取了密码。这其实就是一个很典型的明文密码加密无效的案例。盗取密码的攻击者直接把你输入到文本框里的密码读出来盗走就行了，总不能特地等到你前端加密完了再傻傻地去读加密后的密码串吧。

这种你要防的话就要回到 ActiveX 控件密码输入盘的年代了，安全控件读不到文本框的内容，输出直接就是加密的，这才有意义。

[ZE3kr]

@lesismal HTTPS 就不是“明文传输”了。我本来就是读过全文才发的。标题是错误的

你这里列举的成本就已经比 TOTP 高了，何况 TOTP 带来的安全性提升是更大的。何况 TOTP 现有的论证和组件是更完善的。以及任何安全上的改动必须要有论证，衡量安全性是有标准的，是客观的一件事，不是简单的“觉得”，可以看下现有的安全模型相关的论文的格式，所以大厂肯定更倾向于 TOTP 的方案

[lesismal]

@ZE3kr #48 标题确实, 我在 append 里有解释了. 因为引用的隔壁帖子, 都是关于 https 载体之上的, 这个帖子起标题时没注意标点符号导致了你的误解, 但是内容上, 并不是在说 https 本身是明文, 我本身也强调了 https 解决中间人

> 你这里列举的成本就已经比 TOTP 高了

你前面帖子里说的是老网站用 1 的问题, 所以我只解释解决 1 中用明文的问题的成本, TOTP 这些都是属于密钥本身格式之外的, 不管密钥用明文还是哈希盐, TOTP 之类的这些都可以加, 所以这个成本不应该用来对比密钥格式本身的成本.

[lesismal]

@msg7086

> 1.为什么成本没增加。

一个哈希盐算法, 设计初期就用上的话也不涉及日后把明文升级哈希盐水, 所以就是初期前端的一层包装, 这个成本你给我说有很大, 那我只能表示佩服了

> 2.增加到什么程度才够？
> 就比如你说的多加一步加密没有成本，那为什么只加一步加密，为什么不加密两次，加密三次？为什么没有成本的加密只做一次。
> 如果加密多次也没问题，那么加密五轮就够了吗，还是五十轮呢，或者五百轮？

清醒点, 这里说的是流程上的明文 vs 哈希盐, 你用什么哈希盐算法是你自己的事情, 里面加密多少次是你自己的事情, 但是对于明文->哈希盐的流程只是一个步骤

你说这个一轮流程加密多少次, 就是硬杠了

[lesismal]

> 为什么 telegram whatsapp 网页版不用明文而是其他设备扫码登陆?
> 因为这才是正确的路线。放弃密码，不要用 what you know 而用 what you have 。

@msg7086 这个正确路线有前提, 要有 app 已经设备认证过然后能扫码. 否则 SMS OTP 或者加上两步验证之类的才安全, 事实上很多大站也确实加了两步验证, 但他们照样也不使用明文, 比如淘宝.

所以我也请各位再看一下我 append 里面的, 为什么很多大站们不用明文. 不要用 github 用明文来反驳了, github 非金融类的安全级别要求算是偏低的了而且因为这明文被爆料过的

[lesismal]

@night98 #20

> 3.服务端安全 现在基本上都标配 Bcrypt 了吧

Bcrypt 可不一定是标配, 这玩意防爆破拿手但是成本高

同样的, 我就想请教下, 为什么淘宝亚马逊不用明文

[lesismal]

> 你前面帖子里说的是老网站用 1 的问题, 所以我只解释解决 1 中用明文的问题的成本, TOTP 这些都是属于密钥本身格式之外的, 不管密钥用明文还是哈希盐, TOTP 之类的这些都可以加, 所以这个成本不应该用来对比密钥格式本身的成本.

@ZE3kr 我不确定是否有误解你 #13 的 1, 因为你说的是密码, 没说是明文密码, 我快速扫内容以为是按照主题在聊密码用明文相关的. 但是你的 2 中有说 HTTPS+前端加密的 跟 1 一样不安全, 所以 1 中应该就是指明文密码, 否则 1 和 2 就一样了, 我有点迷惑. 另外, 这里 2 中通常不是加密, 密码不会太长当然加密算法也能用, 但通常是 hash 指纹这些

[msg7086]

@lesismal 哈希加盐以后，哈希加盐的结果就是密码明文了。

所以你只是想保护用户自己想出来的密码不会被人看见，而不是保证一个能通过认证的密码不被人偷走，是这个意思吗？

[msg7086]

其实这帖子我看得很懵，不知道你这个操作到底是要达成一个什么样的效果。

现在我们假设用户的密码是 "3m&y5oDChc"，然后你用 JavaScript 做了一次运算，比如说 md5(password+SALT)，得到 "123456abcdef" 这个 md5 。

你的目标是保护 "3m&y5oDChc" 不被人偷看去，是这个意思吗？

[msg7086]

看了你贴的知乎讲 github 和百度的那个帖子。但是有趣的地方就在于，百度的登录请求的那张图里，其实并没有做过 MITM 中间人防护。也就是说，虽然客户端找服务器拿了公钥，加密了密码然后再发回，但其实客户端并不知道拿到的这个公钥是真的由百度发出。HTTPS 证书世界里，要伪造可信证书是很难的，要是哪个厂敢生成他无权生成的可信证书，没几天他的 CA 就要被全球吊销了。但帖子里讲的这种非对称加密就没有这种认证机制。如果有人有心去主动攻击百度的登录服务，这种额外的加密是不堪一击的，攻击者只要自己生成秘钥对替换掉百度的公钥，然后从用户侧拿到数据解密即可完成密码破解。

[ShuWei]

哎，既然都已经默认用户端不安全了，那哈希也是没意义的啊，上客户端吧，客户端上个驱动，禁止一切可能不安全的行为。至于不能让服务端知道用户的密码，这不更扯淡么，服务端知道与否有什么区别呢，不应该是服务端要注意处理方式么，比如不要明文存储在任何可能被攻击的地方，比如数据库、日志，用完立马清除掉

[Leon6868]

思考一个问题：假定服务器安全，攻击者是否能完全复制受害者的网络特征并给服务器发包？如果攻击者能做到，那服务器如何判别请求来自攻击者还是受害者呢？

很明显，如果你假定受害者全部的网络行为可以被任意截获或者监听，那么信任链根本无法建立，任意加密、验证手段在中间人面前都是纸老虎。

[saranz]

不管怎么说，我相信的只有通知和记录。
通过通知功能实现对用户的提醒，通过记录功能使用用户知道那些行为为非已操作。

在服务端，私有的加解密方式也很是一种对不确定的密码安全的防护。

[mightybruce]

首先，你说的密码是身份认证和资源授权相关，不是加密

身份认证体系有哪些，我这里列举一下


那个知乎链接中对中间人攻击其实一点都不懂， 不了解 TLS 如何工作， 干的事情也是脱裤子放屁

我要再次强调一下任何加密没有安全认证和解决身份和信任问题都是可笑的。