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

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

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

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

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

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

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

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

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

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

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

iseki

126 天前

@lesismal 工程上多一行代码也是有成本的，不能做不划算的事。我可以接受口令在妥善的哈希后传递给后端，但我不能接受把口令 base64 之后传给后端，base64 在这里就是一个收益近乎为 0 的操作（即使它的成本很低），总结下来就是一句话，不做不必要的事。
避免向后端传递原始口令是有必要的（中间设施，日志系统，甚至后端服务本身都可以有缺陷和风险），但必须弄清该怎么做，而不是简单变换一下弄得一眼看不出来就完了。

LnTrx

126 天前

看到现在还是觉得，HTTPS 内密码只能就来解决“有坏人但又不完全坏”的场景，例如：
1. 后端人员出问题原则上什么都可以拿到。但是也许有人看到明文 log 心生歹意，但是密文 log 就不去细想。
2. 中间人出问题原则上什么都可以篡改、窃取，但是也许有中间人只会拿明文 log ，不会分析前端加密、不会篡改前端直接拿到明文。

换言之，这种方法可以增加安全性，但增加的是非常狭窄的场景。同时，给工程增加复杂性、营造虚幻的安全感也可能会降低安全性。因此，不同厂商可能会有不同的取舍。

lesismal

126 天前

> 本来以为开个帖是和大家一起讨论的，结果只看到过强的主观意识

我的 "过强的主观意识" 都有对应的场景和逻辑解释, 所以是就事论事讲道理. 我没有看到你列举这些, 包括 #22 提到的, 你都可以在我的帖子或者 append 和回复中找到对应的逻辑, 但是 #22 有逻辑吗? 如果有, 兄弟你能回答下 #42 吗?

@agag 请拿事实和逻辑说话, 不要随便给我扣这种你门以为的我是 "主观" , 对比事实和逻辑, 再来说咱们谁更主观谁更客观

ywisax

126 天前

要看你是什么角色去对待这个业务。
你是安全人员/东厂/网安爱好者，你对业务的要求一定是“更加安全”。
你是业务开发/需求方/老板，你对业务的首要要求一定不是“更加安全”。

网络安全是要靠事故驱动的。既然“使用 HTTPS 用明文传输密码”不是一个明显的安全问题，没出过事，那就没必要投入，你是项目负责人你也会这样选择，没必要的东西为啥要增加成本。

cp19890714

126 天前

这本质上是职责问题.
网站在安全方面的基本职责是, 保证用户使用网站的链路可触及的范围内, 保证用户信息安全, 包括:
* 传输过程安全
* 运行中安全
* 存储安全

如果用户本地不安全, 使用了代理, 有中间人等等, 这些是否是网站的安全职责所在? 我认为肯定不是.
客户端 hash 固然可以提升一定的安全性, 但这会导致网站的安全职责无限扩大, 到什么范围才是个头?

不同层级的应用负责本层级的安全就可以了. 职责不应该无限扩大.
界定职责范围, 在各自范围内自治.

iyaozhen

126 天前

我先说一下讨论的基线，一般流程：
https 明文密码+后端 salt hash 存储

再说楼主的方案：
[因为简单的不使用明文只需要哈希盐一下]

比如中间有泄露的可能，假设是在 CDN
对于我自己的网站，黑客还是可以直接使用前端 hash 的结果重放。策略无用
最大的作用是这个密码不能去其它网站撞库了

但带来一些工程上的复杂性，前端 salt 如何轮换？

当然前端 hash 这个问题也是月经贴了。这个不是重点，我的意思是现有方案已经足够安全了（一开始说的基线），前端 hash 并没有安全太多。

lesismal

125 天前

@iyaozhen #154

我的观点一直没有说不用明文能避免一切隐患，而是说，要避免完整链条上的，例如爆出来的 github 后端日志以及其他公司也可能有开发者“不小心”这样做。

我在 append 里也有说：
```
一共三个 part: client 端的安全, 传输信道的安全, 传输信道之后的 server 端所有流程的安全. 这其中不只是技术本身的算法流程, 最高可以到社工范畴

你们很多位, 只盯着 1 或者 2 个 part 说没用. 但目的是让完整链条的安全级别提高.
```

所以你们各位说的这些重放也好，https 信道也好，都不是重点，因为这只是我说的 3 个 part 中的 1 或 2 个而不是全部，hash 解决不了重放的问题，明文解决不了前后端泄露的问题，各自有各自解决不了的问题，所以如果业务安全级别要求高，就应该努力提高每个环节的安全强度，尤其是这种本来就可以使用非明文且不需要太高成本的场景

lesismal

125 天前

@iyaozhen #154, 或者我的所有楼层的 key point ，与之前好多帖子讨论为了安全需要 HTTP 不允许使用 PUT 是否合理类似。

很多人看问题喜欢抓几个点，例如：
1. 这个东西可以这样用，用对了没问题
2. 这个东西有大厂再用
3. 大家都这么用了这么多年，你认为不好你 sb

但是这帮人很少考虑过更全面的关联的东西，例如：
1. 除了他自己负责的链条环节，其他关联部门工种的环节
2. 可以这样用就是最好的方案吗？
3. 工程上的其他替代方案是否更好，或者说替代方案有没有增加成本？

前面有位提到“如无必要，勿增实体”，我也回复过。这个原则很对，但首先得想清楚，这个地方是否“无必要”

viruscamp

125 天前

如果你能推进网站前端采用密码哈希方案了，你就不能推进网站后端采用 bcrypt 或更安全的验证算法，推进网站后端 log 脱密记录？后面两件事的优先级怎么都比前端 hash 要高的吧？如果网站后面两件都做了，前端 hash 就没意义。如果网站后面两件都不做，他会听你的意见采用前端加密吗？

关于“密码(口令)明文是隐私, 不应该让服务端知道的隐私”，不可能所有网站都采取前端密码 hash ，只有一视同仁，每个网站都用随机生成长密码，记录的事交给密码管理器(windows 自身，linux 的 kwallet ，keepass)，你记忆的密码只有密码管理器的。