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

[duron600]

哦。

[flyqie]

@flyqie #80

看不到原始密码指的是使用摘要算法，而不是加解密算法。

[InkStone]

@zhenjiachen 又不在前端持久化存密码，你要加密干嘛？

bcrypt 跟传输密码的哈希又不矛盾

[abcde123456789]

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

不是很理解，你的意思是 https+密文就安全了，就不需要有二次验证之类的额外的安全策略？

[yuyuf]

@msg7086 支持。我也是这个想法。
另外 OP 不防把你的具体方案说出来。你只说了密码不要明文传输，具体怎么实现了。hash 吗？

[cslive]

前端加密脱裤子放屁

[yuyuf]

密码 Hash 后再传输跟明文有什么区别？这种情况，你的密码就是 hash 后的结果。

要说真不要明文传输，那方案就是客户端\前端加密，服务端解密。这个 https 已经实现。

[dzdh]

google / facebook / payoneer(即便是支付密码) / stripe / paypal / BankOfAmerica(即便是支付密码) / outlook / nasa / nsa

以上都是 https + 明文，不觉得有任何问题。


说本地木马：跟明不明文已经没关系了，咋不说键盘记录器呢。

[dbskcnc]

在这个问题上，我完全支持楼主，为什么会有那么多密码库泄露，就因为有这些自以为是的人传输和保存明文密码.

[zhenjiachen]

@InkStone 我没说在前端持久化密码啊，我说的是 bcrypt 哈希是在后端做的并且保存到数据库。

[yuyuf]

@lesismal 啥 token 不 token 的。你都没理解人家说的。他的意思是这个哈希值就是明文密码。
明文比 hash 具有更多的被窥探可能性？。啥叫被窥探可能性？

[InkStone]

@zhenjiachen 不持久化存就根本不需要 AES 加密啊。即使要加密也可以用非对称加密，这样就没有逆向破解的问题。

而且前端可以直接做 nonce+hash 的 bcrypt——至于原因，前面某楼已经说了，哈希跟加密相比，最大的区别是避免后端得知密码明文。

[dzdh]

有罪推定：

既然你是明文传输，那你绝逼往日志里写密码了，还特娘的是明文。你特娘肯定数据库里存的也是明文！！艹！

[janus77]

我是支持 op 的，我说几个比较极端的例子
1. 网站的员工在后台日志里看到明文密码了，拿去尝试登录
2. 被任何第三方窥探到明文密码了，然后“拿这个密码去试其他网站的登录”

[vczyh]

1.为什么要 HTTPS ？
2.为什么要 HTTPS+加密？
3.为什么要 HTTPS+加密+签名验证？

搞清楚 2 为了什么，为了更难破解？没有问题，你可以套 N 层加密，包括自己再实现自己的双向认证。

但这样能说明 1 就不安全了吗？如果是的话，HTTPS 有个毛用，所以我依靠 HTTP 安全性有什么问题？你密码加密，别的 payload 加不加密？

3 方案也有很多在用，加大爬虫难度等等，那是不是不用就不安全了吗？

你可以选择任何上面的方案，但没什么最好的，只有更安全，没有最安全，但我个人同意前面有人说的如无必要，勿增实体。

[zhenjiachen]

@InkStone 我是说不赞成前端使用 aes 加密，看清楚哈，前端使用 bcrypt 是认真的吗，前端使用哈希算法，后端保存明文？这就离谱，肯定是前端传输明文后端使用 bcrypt 来做对比。

[cnZary]

前端是可以篡改的
我既然可以接触到你的设备可以解密 tls 内容
那我加密相关的代码帮你注释掉就好了
中间人的时候再给你加回去

[zengxs]

能做到 mitm 的肯定得往你的浏览器加根证书，这分为两种情况：
1. 恶意程序添加的。这种情况恶意程序大概率也能控制你的浏览器，他只需要再监控你在浏览器的输入即可，无论前端是否加密你的密码都有可以暴露。

2. 你手动添加的。这种情况应该属于用户自己要避免的。

并且无论哪种方式实现的 mitm ，攻击者都可以通过注入一个恶意脚本来实现获取用户输入的密码，所以任何加密方式大概率都防不了 mitm 。


那么回过头来看密码前端加密，其实这一点能防的就是厂商拿到明文密码了，但是厂商自己开发的程序，他怎么可能会去防自己呢。
很多厂商巴不得多知道你点隐私。

[belin520]

10 年前，我们接到一个客户的需求，帮他们做了
然后需求我们打上了 “伪安全需求”标签

没有想到 10 年后还有人讨论这个话题

[wanguorui123]

安全是分为不同层级的：
应用层安全：防止暴力破解、防止 XSS/CSRF 、防止 SQL 注入、防止 WebShell 注入
传输层安全：防止中间人对消息篡改和监听、防止消息来源造假
物理层安全：防止数据丢失损坏反转
安全是水桶效应只有每一层都做好安全才行！