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

lesismal

125 天前

@wanguorui123 #100 完全同意, 就是应该在各个层级尽量做好. 好些坚持明文的在这用自己做了五十步的安全笑别人百步, 我感觉他们就是因为明白了一些算法本身, 然后只思考整个环节中的一两个环节从而忽略整体, 可谓是头疼医头, 脚疼医脚, 不管全身

lesismal

125 天前

@bullfrog 要是想聊技术问题, 就正经拿出你的技术观点聊, 这种戏谑的例子跟帖子内容基本没有关系, 习惯了这种不去真正思考只喜欢戏谑的思维方式, 只会成为兄弟你技术进阶的阻碍. 当然, 如果家里有矿无所谓技术进阶, 那你随意, 我也不 care 这些

kinkin666

125 天前

明文传输密码的页面估计也允许保存密码，而且在密码框里也是明文密码，近源攻击的时候摸到机子上去直接 F12 把 type=password 改成 type=text 就显示出来了

lesismal

125 天前

@qq135449773

> 二次验证防止的是未经授权的用户登陆操作，防止的不是密码泄露。

我也没说二次验证是防密码泄漏啊，就是因为密码（不论明文不明文）都可能泄漏，所以才要二次验证这些额外的打补丁。但不是说有了二次验证密码就可以不在乎了，否则还要密码干啥，都走 SMS/EMAILS 之类的 OTP 登陆更省事了但用户又说你强行要我私人手机号了。。

> telegram 和 whatsapp 这类东西，包括微信，做扫码登陆，因为他们本来主打平台就是移动端，只是顺便做的其他平台而已，所以才敢这么做，至于安全与否完全只是顺便而已。

是不是顺便我不知道，但安全问题，如果安全级别要求高，我们不应该用“顺便”的方式来思考

> 给密码再加密一层，密码是安全了，返回给用户的 session 你也要加密返回给用户吗？

例如 JWT 吧，它确实是 server 加密后返回给 client 的，你的用法或者理解是不是有什么误会

> 像 CDN 、WAF 这些做 tls offloading 的东西，还有一些其他公有云设施，这种东西你只能默认信任。
> 假设你以上所有东西都 ok ，你怎么确保你公有云 instance 的云盘或者云数据库不会被未经授权的读取？

同样的，你的这些观点就像我回复其他人的以及 append 里讲的一样，不要只关注我所说的一两个 part
用别人服务默认信任、别人也应该尽量提供保障，这个我没有否定过
重要的是，各个流程链条上，各自尽量做好自己环节的事情，三方厂商做好自己这一层，出了问题它是要赔钱的，我们不能确保三方一定不出问题，所以自己方负责的链条也做得安全强度更高，有错吗？

> 所以就不要自己骗自己了。

这句话我建议你先送给自己，然后好好看下我、以及与我持相同相近观点的各个楼层或者其他地方的知识点

lesismal

125 天前

@LuckyLauncher

> 电商领域有没有可能考虑的不是安全性而是反爬机制

都重要

> 你看看他们的风控就知道了，以前淘宝的风控被诟病成人类都无法使用。

这反到可能是因为他们反扒导致功能上频繁让用户验证导致用户诟病, 如果只是设计正常的登陆反倒可能不至于被诟病, 我用淘宝不多, 所以也不能确定是怎么回事

> 当然这只是我的猜测，至于厂商为什么选择加密只有他们做加密的人知道了，可能亚马逊和淘宝选择加密的理由还不一样。

不要随便猜了, 就不能看下我这么多发言的内容吗, 但凡大家能用冷静分析的态度来思考这个问题, 而不是一开始就拒绝观点, , 也不至于这么多人还坚持明文了...

我琢磨可能是因为, 很多人自己这样用了习惯了, 所以这是属于舒适区, 人的天性就是难以从舒适区里出来
加上经济学上的"沉没成本效应", 因为自己学习领会了一些 https 和加密相关的知识, 就使用这些知识点头疼分析头脚疼分析脚, 只管自己处理的环节, 从而忽略了整体流程上的完整安全

livin2

125 天前

表面分歧在安全实际在于成本，hash 加个盐确实没啥成本。但是，OP 你也看到了，这沟通协调的成本也是成本。有完善的规约/文档，没有存量的屎山，那当然没问题。而现实往往是扯皮甩锅能少干绝不多干的击鼓传屎。
"脱裤子放屁" ？很多时候其实是在屎山面前对括约肌没有信心。
"数据库不存明文"不也是得靠别人脱裤来教育。

lesismal

125 天前

@livin2 #186 对, 对于老项目是这样的. 但对于新项目可以避免这些

LuckyLauncher

125 天前

> 不要随便猜了, 就不能看下我这么多发言的内容吗, 但凡大家能用冷静分析的态度来思考这个问题, 而不是一开始就拒绝观点, , 也不至于这么多人还坚持明文了...

你不猜你怎么知道哪些厂为啥不加密？这两家都是你主导的还是你认识主导这个需求的人？你不过也只是在按照你的方向猜测罢了

lesismal

125 天前

> 你不猜你怎么知道哪些厂为啥不加密？这两家都是你主导的还是你认识主导这个需求的人？

@LuckyLauncher 我都是在按照逻辑讲安全的, 因为一些人举例子 github 说大厂用明文所以就该用明文所以我举大厂的反例

> 你不过也只是在按照你的方向猜测罢了

我不是靠猜测, 都是按道理按逻辑在讲. 我举例子反驳他们 github 的例子, 虽然我没有说原因, 但我相信不用猜测——因为大厂不用明文的原因就是为了更高的安全强度, 这些不需要认识他们主导这个的人

DefoliationM

125 天前

可有可无把，前端代码都是相当于公开的，加不加密无所谓，倒是二次验证 totp 这些支持一下还是很有用的。借用电脑这种，直接电脑装个键盘记录器更简单，20 年前网吧盗 qq 不就用的这种。可以学那些光刻机的那些控制系统，整个系统全部自己定制，全部加密，销售直接卖整台设备。

hcbb

125 天前

客户端都不安全了，前端加密有什么用，掩耳盗铃。需要另一客户端也进行验证还靠谱些。

mayli

125 天前

一般来说，业界会使用成熟的加密算法和方法来进行验证，也就是不会自行发明轮子。例如安全密码验证会使用类似 bcrypt 和 salt 之类，为了增加安全性引入 2fa 。这种经过验证的安全性技术，用起来一般都不容易出现安全性问题。

对于题主的不信任 https ，进而选择在客户端进行“加密”，在安全性分析逻辑上其实属于“混淆”。因为客户端代码和逻辑都是可以被逆向和检查的，从传统的安全性上来说，基本上属于事倍功半的行为，而且一般情况下，系统的复杂度与漏洞数成正比，可以说系统越复杂存在的漏洞就会越多。引入一个这种技术，大概率是面向 KPI 的 feature ，而不是真的传统意义上的安全。比如说，你如果是客户端实现加密，是否需要引入 salt 或者 key ，那么这个 secret 是否也会通过所谓不安全的 https 通道传输到服务器，这个 secret 服务器需要明文还是可以进一步 hash ，这些都是当造轮子时需要考虑的问题。

当然，另一角度也可以说，我这是特别强力的混淆，就像 D 加密那样，没人可以逆向。这么说也行，不过对于实际场景来说，解决明文用户名密码泄漏的 2fa 技术已经足够流行和有效。即使在 http 情况下，也能一定程度避免 replay attack ，所以大部分公司没有必要投入资源去实现客户端加密。

所以和大部分计算机系统一样，当一个方案已经足够好，另一个方案没有明显优势的情况下，就不会被替换。

另外关于第三方的论点

> 重要的是，各个流程链条上，各自尽量做好自己环节的事情，三方厂商做好自己这一层，出了问题它是要赔钱的，我们不能确保三方一定不出问题，所以自己方负责的链条也做得安全强度更高，有错吗？

“我们不能确保三方一定不出问题”这个思路倒是正确的，但是大部分工业场景是妥协的结果，也就是预算情况下的最廉价解决方案。比如 TCP 本身已经保证不会丢包和乱序，在 tcp 初期，这个 tcp 第三方因为不被信任所以好多程序会自己发明个网络协议。但是 2024 年，不会有程序在 tcp 层上面再去检测乱序或者丢包，大多数情况下，文件传输后，算一下整体的 hash 就够了。妥协的结果就是，大部分的底层结构已经足够可信，对于登陆安全性方面，fidelity 用的明文，chase 用的混淆，我觉得都可以接受。

lesismal

125 天前

> 对于题主的不信任 https

@mayli 我可是完全没说过这话啊兄弟, 你和其他很多楼一样, 几乎完全没 get 到我说的是什么...

parareptilia

125 天前

防撞库?

viruscamp

124 天前

我觉得 OP 有点迫害妄想症了，用户不相信网站，网站前端部门不相信后端，后端部门也怕开发人员假装无心 log 打出来了。

那 OP 也应该怕前端加密的 js 的代码里藏了记录原始密码的后门。

我建议别用担心的网站，非要用的话，一定要一站一码。

OP 信任密码管理器吗？操作系统或浏览器自带的密码管理器呢？再关掉密码同步功能呢？都不信的话，用个小本子记吧。

jacksparrow414

124 天前

看了目前为止所有的回答，我还是同意 @msg7086 说的。首先就讨论问题来说，他没有代入情绪，即使有分歧，他还是在确认分析，然后给出自己的想法。其次，就解决方案来说，我们的工作流程和他的大概类似，一件事在公司角度来看，是需要有效益的。所有的成本都要计算在内，如果效益不明显，还浪费了很多人力资源，公司显然不愿意主动去做。除非这件事影响到它的生存或者重大利益了。个人的话，你想怎么干都行；公司的话，还是有很多因素要考量的

bullfrog

124 天前

指纹本身就是技术问题，可以解锁很多东西，即使现在用不到以后也可能用到，而且指纹无法改，在你摸门把手电梯按钮的时候都是明文传输，最应该做好保护，当然如果你家里有矿不怕偷，那也随意，我也不在乎这些

msg7086

124 天前

@lesismal
> 你有没有想过, 很多黑产搞到东西, 但每年我们看到的新闻有多少? 被你知道的泄漏了的只是冰山一角, 你没看到不代表明文就安全了, 也不代表改造后就没带来更全的安全性.

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

你尽管叫破喉咙，但破喉咙是不会来理你的。决定企业做什么的是企业的老总，是 org 的负责人，是 PM ，是 tech lead ，不是你。当然你可以自愿加班去完成我上面说的那些，但这关我什么事呢。你是想说服我无偿加班给公司项目加这个功能吗？我可太谢谢你了。

在资本的社会里谈理想，你的想法是不是有点太甜了。

msg7086

124 天前

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

这么高一层楼 200 来个回复，说句实话，非常给你面子了，因为讨论的过程还算礼貌，v 站大多数人也不愿意说脏话。换到激进点的论坛里，就不知道是你保卫家人在先，还是管理员看不下去直接 ban 号在先了。帖子内容太过贫乏，甚至激不起我一点讨论技术的欲望。有句话叫，非蠢即坏。看你讨论过程，好像也不像是坏，那可能只是真不懂了。但最可怕的是不懂还觉得自己是对的，有一种老子说的才是对的，你们不同意那一定是你们都是傻逼。那这就没法聊下去了。

大家的耐心是有限的，有些人「蠢」，是因为缺乏知识，旁人点拨一下，去学习了知识，懂了，就不「蠢」了。有些人坚持自己错误的想法，大家劝了劝，发现没什么用，那只好 block 之，以免浪费自己时间。

看到这种纯粹引战的 append ，我的耐心已经用完了。觉得自己老牛逼了，看别人都觉得傻逼的人，我诚挚建议你，以一种圆润的动作姿态离开这个看法和你不同的人组成的社区。

言尽于此，block 了，请勿再回，我不会收到提醒，也不会再浪费更多的时间在这个帖子里了。