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]

> 谁出钱谁说了算。你出钱吗？你不出，所以你说了不算。

公开的技术讨论, 各自公司自己的事情自己负责, 你看见我什么时候说过我说了算了要求你们所有人都要按我说的做了?
但是, 我公司的项目就是我说了算, 你也管不着

> 你自始至终都没有对 Before 和 After 做过具体的案例分析，帖子里基本就是一些假大空的呐喊，什么坚持明文啊什么舒适区啊什么天性啊。怎么不上点干货呢。

哦哦, 和着我说的技术逻辑安全逻辑安全原则和举例子之类的, 都算是假大空是吧? 我说了那么多逻辑原则例子你思考吗?你不思考还狡辩解释那么多层然后被逼的我说你舒适区有错吗?

> 这么高一层楼 200 来个回复，说句实话，非常给你面子了，因为讨论的过程还算礼貌，v 站大多数人也不愿意说脏话。

怎么的, 有些个小孩子上来就说"你水平低"之类的, 你见我说几句脏话了吗? 聊个技术还怕别人喷, 那就不要出来聊

> 换到激进点的论坛里，就不知道是你保卫家人在先，还是管理员看不下去直接 ban 号在先了。

自己说不过了, 就改成威胁别人要骂人了是吧? 我不 care 低素质的人, 你随意

@Livid 我感觉这是在威胁骂家人了

> 帖子内容太过贫乏，甚至激不起我一点讨论技术的欲望。有句话叫，非蠢即坏。

蠢和坏也是要以事实逻辑为依据, 我每一个点都有对应的解释, 如果你看不懂然后以为我蠢, 那你也随意, 你嫌烦的话可以直接 block 我

> 看你讨论过程，好像也不像是坏，那可能只是真不懂了。但最可怕的是不懂还觉得自己是对的，有一种老子说的才是对的，你们不同意那一定是你们都是傻逼。那这就没法聊下去了。

你看看你这两层的回复, 谁在假大空?

@msg7086

[lesismal]

@viruscamp

我已经发现了, 讲的原则逻辑和道理各位基本都不怎么看, 所以我举例子请教各位, 淘宝亚马逊不用明文, 是为什么?

github 日志输出明文的问题暴出来大家也"多数人"认为这是问题, 为什么? 我这里说"多数人"而不是说"所有人"认为这是问题, 因为我发现可能并不是"所有人"认为这是问题, 比如各位坚持明文的

[lesismal]

@viruscamp 跟前面好多层一样, 兄弟你这也是没 get 到

[lesismal]

@msg7086 虽然可能 block 我了, 但说不定你 logout 能看到, 所以补几句吧, 你让我举例子, 我说黑产黑了的很多没曝光出来你又说我假大空, 那你可以看下 github 的例子, 可以看下 #158 cdn 脱裤的例子, 淘宝亚马逊以及#174 微信的推荐设计

自己脑袋一热也不认真分析下我的回复, 就无脑喷我, 只会限制你提升自己的技术层次, 这跟我所理解的原因(病因)八九不离十, 就是舒适区和沉没成本, 另外一个词就是"聪明反被聪明误", 因为自己懂了一些, 所以拒绝接受不一致的. 但技术需要冷静分析, 论坛上讨论技术我多数时候是一就是一二就是二, 不喜欢模棱两可去赞成别人, 所以我的观点如果和你不一样的时候, 你可能会觉得我带着情绪, 但不是, 技术的东西是实在的, 谁也不给谁发工资, 不需要看脸色

[Hawthorne]

明文的问题是，你泄露的不光是这个密码，而是你密码的生成范式。
而且，如果每家网站的客户端生成的密码 hash 不一样，你甚至可以全网使用同一个密码。

[testcaoy7]

我也是不赞成传输密码明文的，HTTPS“并没有”许多人想象地那么安全，尤其是国内环境，很多人并不会注意系统里面的 CA 证书，而不少软件都会在安装过程中在系统 CA 里面加料。

这也是为什么网上银行密码需要单独安装独立文本框控件，大额转账需要 U 盾之类的电子密码器的缘故。

许多人将银行的系统视为技术老旧，心中颇有微词，其实银行那样是有道理的。目前我发现的趋势是，越是喜欢炫技的网站、产品，出问题越是多。

[Hawthorne]

@yuyuf #91 我的理解是明文密码泄露除了泄露密码本身，还泄露了个人密码的生成范式或生成习惯，甚至个人隐私信息——可能这就是“更多的被窥探可能性”。

[llsquaer]

讨厌一个句话 “你电脑本身不安全了，就不用再考虑安全”。

不知道谁说的， 典型的就是之前讨论 Chrome 可以本机自由的导出历史记录，保存的密码。然后就有人解释说了上面一句话。

但是在我有限的理解来看，Chrome 不是应该自己在加一个密防止导出么？

[maplefly]

我只能说如果经历过红蓝对抗，那么只要你传输没有加密，就会被通报

[zlowly]

我觉得楼上很多人对数据安全问题还是了解有限，如果你不是这里数据安全领域里摸爬滚打过，就不要轻易下结论。如果你身边有参加过 HW 的，或者打过 CTF 的同学同事，先去和他们请教一下 HTTPS 用明文传输密码的风险，了解一下为何有了你们都觉得安全的 https ，在 CTF 里还是有 wiresharp 分析 https 流量的赛题。

[zanpo]

https 用明文传输有啥问题，假设我使用 https 明文传输密码，客户端安全，TLS 握手时校验服务器证书，你能在网络传输的节点截取我的数据能看到明文吗？ 你界定了使用 https 明文传输密码就不要扯东扯西。只需要讨论在传输过程中你如何截取到我的 https 明文数据就行了。

你的所谓例子没有一点意义，客户端不安全有啥好讨论，我种个马拦截键盘输入，你明文密文传输有区别？你输完密码，我 F12 调编辑框属性我看不到你的密码？你输入密码，我调试程序，内存里面看不到你的密码？你明文密文传输有区别？服务器不安全有啥好讨论，你密文传输，服务器端不照样解密，内存中存在明文密码？服务器不安全，你明文密文传输又有何区别？

本来 https 就是基于 TLS 的传输层安全协议，假设你可以在我和服务器中间的任意路由节点上拦截到数据，你只需要告诉我怎么从 https 数据中拿到明文密码就行了。

[liuminghao233]

你的意思把密码 hash 一下就感觉安全一些
再 hash 一下感觉又更安全了是吧
实际上没有提升安全等级
解决安全问题的是 2FA ，而不是你所谓的“明文加密”

[iyaozhen]

@zlowly 看你说的 我自己也想了下。虽然在大公司，但很多时候都是螺丝钉， [身边有参加过 HW 的，或者打过 CTF 的同学同事] 真的很少。业务部门也就有安全工单的时候和安全部门有接触。倒不是说不关注安全，功能开发能按安全 SOP 做好就已经打败 90%的人了

[zlowly]

要从 https 数据中拿到明文密码，一种可行路径是：扫描关键服务器的信息泄漏漏洞->获取服务器私钥->攻击服务器侧其余薄弱服务器（如测试环境）->横向渗透或抓取服务器段流量->解密服务器 https 流量。通过此途径，可以在没有取得关键服务器的管理、修改权限的情况下，仅凭中风险漏洞就能从流量中获得用户密码等信息。
还有更多其它方式。现在复杂的部署环境，我觉得大部分人都只能负责一小块，服务器、网络、WAF 、负载均衡等等不可能都完全由你掌握，例如有些设备由于性能还要求你先卸载 SSL ，光靠 https 一劳永逸不实际。
也许你会认为这是服务器安全加固责任之类问题，和 https 无关，但是在 HW 、会议等敏感时期中一旦出现安全事故，保不准哪位哥们为了减轻责任，就是把你密码明文传输赖上，为了撇清责任你的上级也不一定会为你说话。
是的，HASH 一下它还是有其它风险，但我自己觉得，多做这一步，不是为了保护数据，而是为了不用提桶跑路。

[forty]

@zanpo CDN 现在挺普及的，用户是跟 CDN 通信，CDN 再跟服务器通信，CDN 其实是中间人，所以有时候你需要让通信内容不被 CDN 知道，就需要多加密一层。比如，敏感内容，你不想被 CDN 检测和谐。

[hesetiema]

Web 前端密码加密是否有意义？( https://www.zhihu.com/question/25539382/answer/1270846719)。知乎这个问题不错，可以参考的。

[xxxccc]

@cndenis 不对吧，当年 csdn 的数据库被扒了，里面存储的用户密码就是使用明文的，导致不少有些人的其他账号也受到影响。
https://baike.baidu.com/item/%E5%AF%86%E7%A0%81%E5%A4%96%E6%B3%84%E9%97%A8/4976608

[iseki]

@lesismal 明文向后端传输虽然不好，但有时这是工程上成本刚好可以接受的方式。一来我刚才说了，很难设计一个有足够收益的非明文传输方案，二来就是有时候后端的某些设施只能接受明文。

[lesismal]

@zanpo 兄弟你根本就没看懂 OP 我说的是什么, 你们好些位这都相当于是盲人摸象管中窥豹, 只考虑 https 或者某个 part, 请先看下我帖子和 append 或者更多楼层的回复

[lesismal]

> 明文向后端传输虽然不好

你看, 你也认为明文不好了

> 但有时这是工程上成本刚好可以接受的方式

如果是项目初期/上线前, 这个成本真的不多

> 一来我刚才说了，很难设计一个有足够收益的非明文传输方案

数据隐私本身不重要的网站, 明文与否都还好, 即使泄漏了也没关系. 我自己注册一些不重要的网站的密码都非常简单, 单手输入满足大小写之类的就用了, 也不怕泄漏, 重要信息的网站就复杂些而且那些站多数有二次验证之类的额外安全措施, 所以也不怕

> 二来就是有时候后端的某些设施只能接受明文

密码这个功能点上来讲, 明文不是必需, 所以如果哪家说必需明文, 那我怀疑这是别有用心...

@iseki