请 [吸词] 的作者出来解释一下密码明文传输的问题

2024-05-23 16:27:24 +08:00
 rambo92
今天忽然发现所有的网站的请求里都有一个固定的 url 请求:POST https://jnexswpfgysrqlagwajs.supabase.co/auth/v1/token?grant_type=password
Request Body 携带了一个我常用的用户名和密码,而密码居然是明文的!!!
这让我很是震惊,密码泄露了???

于是开始排查:
1. 打开无痕模式:随便打开个网站,没发现这个请求,于是确定跟插件有关;
2. 关闭所有插件,一个一个打开,最后定位到 [吸词]

原因找到了,那么这个是为什么呢?
1. 为什么密码要明文传输?
2. 为什么所有网站的请求都会发这个请求?插件干啥了?

https://cnnbrba5g6haaugeu530.baseapi.memfiredb.com/storage/v1/object/public/images/public/1.png
14785 次点击
所在节点    程序员
109 条回复
lesismal
2024-05-23 21:41:26 +08:00
@zhangjiashu2023 #78 明文本身也是存在问题的,hash 强于明文,hash+2FA 是强强联合,强强大于强,所以没必要因为有了 2FA 就用明文降级强度
BeautifulSoap
2024-05-23 22:18:39 +08:00
@Jirajine 啊,对了。。。有一点差点绕进去导致我说漏了,lz 你再仔细想一想,当中间件真的输出了你的密码请求体,请问这时候输出明文密码还是 hash 加盐之后的密码有非常大区别吗?

按照 lz 的想法,需要在前端完成加盐 hash ,那么这个“盐”必须要存在网页或 js 代码里吧,那么对于一个都有能力去攻击你系统内部中间件的人来说,浏览器 F12 看一看你前端登录时用了什么“盐”是很难的事情吗?
这时候攻击者有了盐值,也有了中间件输出在 log 里的 hash 后的值,他要做的就只是跑一个彩虹表的事情。对于不复杂的密码这么做和明文是没区别的,该撞库你还是挡不住。而对于复杂密码的确彩虹表是跑不出来的,但一般非常复杂的密码往往都是随机生成的密码 or 用户根据自己一套规则生成的动态密码。你哪怕跑出来也没办法拿去撞库

再说一下,后端密码入库前必须加盐后再 hash 才会更安全这点,原因不在 hash 上,而在于 “盐是保密的” 这一点上。后端的盐除非出了致命漏洞被黑客侵入了服务器内部,一般来说是根本不会泄露的。因为“盐保密”所以这种做法才是安全的。而在前端加盐,这个盐是明文公布给所有用户的,也就是说加盐等于没加。
mightybruce
2024-05-23 22:46:55 +08:00
说实话,除了不想让服务端或这个服务商获取信息外需要再次在内容加密外,我真的看不出有必要,也就是端到端加密这种才需要再次对信息内容加密,


密码学本身对于大多数程序员实在太过遥远,这门专业的领域谷歌等大公司在具体业务方面有时候都能爆出问题,就不要说普通程序员的理解了。
有很多算法是根本不需要密码这种体系的,但是成本高实现起来也难,就说几个吧
1.基于身份的加密体系 IBE 可以做到不依赖公钥基础设施 PKI 来保证安全
2. 同态加密, 加密信息搜索以及各种之上的运算能达到明文的效果,可以确保隐私数据没有任何人能看到
3. 谷歌的零信任安全项目 beyondcorp 的系列论文
mark2025
2024-05-23 22:51:43 +08:00
@FTLIKON
1. 创建账户/修改密码的时候,后端用一个全局固定盐 globalsalt 与用户口令拼接后使用摘要算法( md5 ,sha 甚至 pbkdf 等等)入库为 pass1 ;
2. 登录的时候,后端生成随机盐 salt1 ,用户输入的口令与 globalsalt 拼接生成 pass1' ,然后拿 pass1' 与 salt1 拼接摘要生成 pass2
3. 后端收到 pass2 之后,取出 pass1 和 salt1 拼接生成 pass2' ,然后与 pass2 进行比较。

globalsalt 的目的是即便用户在不同网站输入的相同口令,也不会有相同的 pass1
Jirajine
2024-05-23 23:04:06 +08:00
@BeautifulSoap 你的论点完全偏题了。无论是密码也好,还是其他信息也罢,只要服务器知道的信息,那就都是一样的,没人关心你要怎么 secure 你的中间件。
They can do whatever they want with your data, and you have no way to know what they did. What else do you expect ?

至于“xxx 所以和明文没区别”这纯属滑坡谬误,假设我在 V2EX 的密码是`mypasswordforex.noerr.eu.org`,看到明文之后你能不能猜到我在其他网站的密码?更不用说很多人的密码文本本身就包含个人信息,如姓名拼音/生日等。
mightybruce
2024-05-23 23:12:56 +08:00
有同学说服务之间调用和日志会暴露信息,可以了解一下服务网格的零信任安全是怎么做的,现在欧美很多大厂要求微服务使用 mTLS 来保证通信安全。
LnTrx
2024-05-23 23:30:06 +08:00
关键要讲清楚,前端加密的目的是什么,要防止什么样的攻击/泄露。对于用户侧的攻击,找不要有意义的场景。对于服务侧,因为会有很多环节,加一层防止意外泄露还算有那么点道理。
tool2dx
2024-05-23 23:46:58 +08:00
前端用明文密码的最大阻碍,并不是 HTTPS 中间传输的安全性问题。而是后端拿到你明文密码后,公司内鬼会干一些什么。
LnTrx
2024-05-24 00:21:18 +08:00
尝试总结一下

用户端:
恶意软件/人员有很多手段获得密码,很难想象一种只有 HTTPS 内明文才能获得密码的场景。(安全的增益太细微)

中间人:
当前移动端安装根证书很难,PC 端需要权限。如果有本事装上,那同样有很多手段获得密码。
既然是中间人,那自然可以篡改网页,从你手里明文获得密码再加密发给网站,双方都无感知。(只有当中间人坏但又不完全坏时才有意义)

服务端:
服务端的安全性根本在于维护人员的水平。维护人员安全意识淡漠,到处都是漏洞,单单密码加密意义不大。
无论前端有无加密/散列,服务端数据入库都需要再做处理。只依赖前端加盐的安全性还是很有疑问。
在某些特定场景,例如网友说的内部人员打 log 出密码。如果是密文可能懒得研究,如果是明文可能会心生歹意。在这种
情况下,加密也许存在一定意义。
ShuWei
2024-05-24 00:29:51 +08:00
有时候,不要过度安全,很多所谓的安全措施其实是掩耳盗铃而已,比如登陆的时候前端先把密码 hash ,都 https 了,不要说什么中间人攻击,既然都能中间人攻击了,先 hash 难道有任何意义?
LnTrx
2024-05-24 00:33:17 +08:00
@ShuWei 增加复杂度有时也会降低安全
jeesk
2024-05-24 02:07:36 +08:00
加密有多大用处? 即使你再加密,你电脑不安全,记录你的密码,你也是百搭。 网站的策略默认你的环境是安全的。 你自己用 debug 不也是也能将密码搞出来,然后就演化成对抗了。

要么学学有些小方案,没有密码只使用验证码登录,直接校验手机和邮箱验证码。
是不是有人杠? 有个拿 q 逼着你登录?我怎么知道是不是有人拿 q 逼着你, 这样下去,所有人电脑都不安全,那成本岂不是会变大很多? 登录首先向网站提交自己没有被 q 胁迫,再登录?

再举个例子, 文件系统, 磁盘不安全有坏道,那么文件系统是不是强制大家做双硬盘? 你不是双硬盘我不要让你用? 反正总有人说磁盘可能要坏,必须双硬盘,否则就是不安全。貌似两种观点都对,但是对于成本和用户体验来说哪个重要?脱裤子放屁的方案太多。
weijancc
2024-05-24 02:24:51 +08:00
真是无语, Google 这几年强推 https 就是为了通信安全, 你还搁这"明文传输", 你用开发者工具看看所有主流网站的登录, 密码都是不会加密的.
hxysnail
2024-05-24 08:50:16 +08:00
如果 https 能被破解,那么你前端 hash 后传输也没什么鸟用,拿到你的 hash 还不照样黑你?如果 https 不能破解,我传明文又怎样,你还不是拿不到?

换句话讲,在传输过程中,数据安全是由 TLS 加密链接来保证的。当然了,在数据库存储时,必须加盐 hash 或采用其他可靠的加密手段,禁止明文。
zhw2590582
2024-05-24 09:25:04 +08:00
不过,chrome 扩展拿到用户密码实在太简单了,而且请求发生在扩展后台里,平常在网页的开发者工具是看不到这个请求的,所以很难让人发现
GODZZZZZ
2024-05-24 10:39:35 +08:00
两个问题:
1. 前端加盐后 HASH ,如果每个用户盐不同,盐存在哪?
2. 如何处理密码强度策略变化的问题,前端验证的话,更新前端代码吗?

我一般数据库设计用户表 password 和盐存两个字段,每个用户盐不同,前端原始密码 https 到在后台进行加盐后 HASH 存储到 password 字段,脱裤也没事。
bitmin
2024-05-24 11:04:53 +08:00
@GODZZZZZ #96

密码怎么还会自己加盐 HASH 保存,怎么不用类似 bcrypt 去加密
BeautifulSoap
2024-05-24 11:45:53 +08:00
@Jirajine so ,你的论点是什么? 这里讨论的是中间件日志被攻击的场景,以及由此产生的安全隐患。lz 认为密码不能明文传输的最大论据之一就是这个。所以我结合自己的实际项目经历指出了 lz 论据根本站不住这个点,请问哪里偏题了?我的问题和质疑点还是没变,你都不信任中间件了为什么还只关心密码泄露这种小事?
encro
2024-05-24 11:52:12 +08:00
是的,将密码明文存储,且不给注销。
encro
2024-05-24 12:01:09 +08:00
已联系作者,上次调 api 的时候发现了,打算发个帖,这几天没空,就没发出来。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://ex.noerr.eu.org/t/1043320

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX