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

[iyaozhen]

楼主你说的没问题，但不是所有业务都需要那么高的安全级别，再直白一点，有成本

“另外更简单的一个思考，如果不用明文、我们实现上增加了什么成本，带来了收益，有什么损失”，我来说说有什么成本：
1. 你密码加密用什么方式，RSA ？还是先 RSA 传递密钥再 AES ？
2. 密钥轮换策略呢？为了安全最后是每个用户密钥不一样，还有保存和轮换的问题
3. 密码要加密，传递的用户敏感信息（比如身份证号）是否要加密呢。你不要说这个不用，按严格的隐私保护策略，也需要，防止中间层泄露
再扯远点按欧盟或者一些其它地方的隐私保护，你很多数据存数据库都是要加密的，但为什么不做，还是成本

https 为什么能铺开，就是因为应用层不需要任何修改，网关加一层 https 就行。再加上浏览器厂商的强制推行，这才普及，不然没人改的。

工作这么多年（ TOP3 大厂），非资金或者涉密相关的业务，就普通 web/app 。安全很多时候都是嘴上说说，而且很多人嘴上都没说对。但近几年为什么安全确实越来越重视了，1 是法律法规的影响（不说欧盟，国内也有，这不信息安全月才过去）。2 是各种平台的严格审核，最常见的就是 Android 日志里面不能打印隐私信息，拒审几次就教做人了 3 是安全事故确实影响大（倒不是说用户信息多少珍贵，是舆情风险）
说的这些并不是说我不赞同做的更安全（反而我是 ToB 的，某些场景为了安全投入了 N 倍的开发成本），但实际情况就是有很多成本和意识问题。

[iyaozhen]

@YangWaleed +1 前端加密方案不拿出来说没有意义

不能高估大家的技术能力，比如短信验证码接口上直接返回的事情都有，前端加密这种更复杂的工程，更容易出篓子。实际就是成本和收益不成正比。

[LandCruiser]

你说的不成立，前后端都是一个公司开发的，加不加密你都防不住它获取你输入的真实密码。因为让你看起来“加密了”很简单，我直接在你输入的每个字符之间随机插入 10 个字符，你看得出吗？后端获取密码后直接隔 10 位字符取值就行了，你忽略了一个重要的点，前后端都是一个公司开发的。
为什么你会这么想？很简单，你的逻辑思维能力不行。

[belowfrog]

@FengMubai #4 你没分清楚，“用户”不想让服务端知道隐私，还是“前端”不想让服务端知道隐私？这里讨论的前端吧，用户能做的就是不要用同一份密码

[iseki]

单从避免用户主口令泄露这件事上来说，要做一个可靠的方案成本比较高，前后端可能会有超过一个 RTT 的挑战响应机制。比如后端存储用用户主口令加密过的私钥，然后在用户代理（浏览器）中完成挑战响应，这样可以保证用户主口令不离开用户代理。
如果前端简单哈希一下，暂且不论能否提高安全性（加盐会很难做，固定的盐没有意义），哈希后的结果会不会缩减值空间，反过来降低安全性，可能也有待评估。

[RainyH2O]

客户端靠密码管理器，服务端靠 WebAuthn 。传输明文肯定是不够那么安全的，不能说某些大站这么做就等于是安全的标准真理。做出不够安全的系统就乖乖立正挨打别嘴硬，不是不能理解因为开发成本等因素不能也不必要做到那么安全，但批评你不够安全的时候心里要有点数。

[lesismal]

> HTTPS+明文的，你倒是不看是吧。

@dzdh 我用亚马逊淘宝, 是针对坚持明文没问题的人, 是举反例, 因为按照你们的逻辑, 就不应该有技术级别足够高的厂商使用明文因为这样做太傻逼了, 我举例是反证法的逻辑. 所以我没搞懂为啥你好意思来反问上面这句

多加强一道更安全一点不是错, 你举那么多用明文的只能说明他们加上其他的验证方案也有很强的安全级别, 但不代表比不用明文的安全级别更高.

[iseki]

此外再提及一点，许多密码基础设施提供的验证接口形如 verify(password, stored_credential) -> ok?，这里虽然没有明说（实际上也不可能要求） password 必须是用户的原始主口令，但一般确实可能影响到实践。

[lesismal]

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

@dzdh 这个我也解释了啊, 木马只是举的一个例子, 实际考虑的是所有可能情况不只是木马

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

我没说过这话, 没有推断别人一定作恶. 但是你用明文, 就存在这种可能性. 算法复杂度讲究考虑最坏的情况, 安全也应该在能力范围内尽量考虑去对最坏的情况做防护, 有错吗?


看你几楼的回复, 感觉我说的啥你都没 get 到吧兄弟

[iseki]

也许可以在前端对口令完成一次困难哈希，但难度和风险在于这个哈希的算法和参数从此固定不能更改，也意味着日后所有的「客户端」都要能自主完成这套逻辑。

[leonshaw]

和数据库不能存明文密码一个道理，不是要防止服务端获取密码，而是防止服务端「记录」密码。如果前端传明文，那密码就有可能躺在某个日志、某次服务 debug 时的抓包文件里等着有心人读取。大厂用明文是因为它相信自己能杜绝上面的情况。草台班子往往只看到了明文传输，没看到后面的安全防护工作，当然也可能根本不在乎。

[lesismal]

> 此外再提及一点，许多密码基础设施提供的验证接口形如 verify(password, stored_credential) -> ok?，这里虽然没有明说（实际上也不可能要求） password 必须是用户的原始主口令，但一般确实可能影响到实践。

@iseki 有人这么做, 不代表这么做更好

看一下我新 append 的, 不是只局限在技术范畴算法范围内考虑安全的, 暴出的 github 那个例子就是这种情况
明文相比于非明文至少是提高了一点点强度的

[lesismal]

@maggch97 确实, 很多人挺专业的, 但只盯着技术本身 1 两个点, 然后说这个也没用那个也没用, 就不能去考虑下除了技术这个点之外的更多场景

[lyxxxh2]

"例如有人借用你电脑的时候给你设置了个代理或者装了马拿到了你的帐号密码" ???
"例如有人在你电脑上装了键盘监控或者在旁边装个针孔摄像头"

再加密下文字可以解决些小安全问题。
但是谁说为了解决小安全问题,而要我加密,我敲死他,吃太饱了是吧。

[csrocks]

我有个问题,
现在假设数据库存的密码是 md5(password+salt+password), 如果需要在前端 hash 之后再传给服务端, 那么我的加盐方式是不是也一起暴露了?

[iseki]

@lesismal 这文本复制的可真有意思，也怪我，下次用 Kotlin 风格的方式表达。
这个接口的风格是工程要求，你也可以看一下我在这条文本之后的跟帖，大概有这么个现实问题是不太好解决的，你可以给出你的解决方案讨论一下。

[kiripeng]

https 的情况下，密码 md5 和 sha256 都是为了让项目组人员安心，跟明文其实没啥区别，在前端各种盐肯定会被暴露。我个人认为是图 [安心] ，数据库存密码加 salt 和非对称加密我觉得才是主要的

[lesismal]

@csrocks @iseki @kiripeng

这个帖子主要意思是完整流程链条安全的更强, 主要解释的是之前帖子里对于明文的分歧, 明文这个问题, 哈希加盐就可以了, 想更强的防碰撞就上更强的 bcrypt 或者非对称加密.

加盐方式方式根本就不怕暴露, 因为是散列或者用非对称加密, 你知道算法也解不出原始密钥. 很多人杠说直接拿着哈希盐去请求也一样, 说的没错, 但是也比直接知道你原始密码在网站上操作要麻烦, 因为他要去分析前端代码然后再去写更多代码, 包括各种应对反爬虫各种.

非明文至少解决一部分前端和后端流程上的直接拿到原始密钥的问题. 正如我前面都讲过的, https 只解决信道问题, https 信道之外的 client 和 server 流程上, 它解决不了. 所以这帖子根本就是不是在讨论 https 信道本身的问题.

任何技术手段都不能完全防止被破, 因为还有社工的可能. 但至少增加破解难度, 难度的提高同样能让很多破解的人失败, 又不是所有你遇到的都是顶级黑客, 所以至少降低了被破的概率.

[wtfedc]

OP 说半天也说不到点了，逻辑有点无厘头，看的是真急。

前端做处理，想到两种场景，跟 op 描述的东西不沾边：
- lifei6671 这个哥们说的，服务提供方是不可信站点，用明文去撞库。
- 预防中间链路被攻击，比如 浏览器 <-https-> CDN/其它边缘节点 <-http-> ECS 这种，如果 CDN 到 ESC 之间的路由节点被攻击，是能拿到明文，但这个是服务提供方考虑的。对于普通用户来说，用大厂的服务，已经默认它的安全性了，再去考虑怎么预防大厂内部出问题，多少有点没有性价比。

前端代码是完全暴露的，额外做的加密也是完全暴露的，即使用 web assemblely 引入二进制，依然是可以被攻击方调用。想从前端本身去加强安全，没意义。

[lesismal]

@belin520 10 年前这个事情, 没人说打标签的人是对的, 所以你得到的结果和结论也不一定准确. 如果觉得当初没必要做, 那可能是 10 年了自己被打标签的人耽误了所以没进步.