这是一个创建于 182 天前的主题，其中的信息可能已经有所发展或是发生改变。
今天忽然发现所有的网站的请求里都有一个固定的 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
Request Body 携带了一个我常用的用户名和密码，而密码居然是明文的！！！
这让我很是震惊，密码泄露了？？？
于是开始排查：
1. 打开无痕模式：随便打开个网站，没发现这个请求，于是确定跟插件有关；
2. 关闭所有插件，一个一个打开，最后定位到 [吸词]
原因找到了，那么这个是为什么呢？
1. 为什么密码要明文传输？
2. 为什么所有网站的请求都会发这个请求？插件干啥了？
https://cnnbrba5g6haaugeu530.baseapi.memfiredb.com/storage/v1/object/public/images/public/1.png
第 1 条附言 · 182 天前
关于前端是否应该对密码hash后传输的观点：
- 密码加盐（每个网站的盐一般都不同）后hash传输，服务端存储的是与原明文密码没有任何逆向关系的字符串，所以即使多个网站使用相同的密码，也不会受到某个网站被脱裤后的影响；
- 基于第一点，HTTPS是否是加密传输其实无所谓的，与密码的安全并无关系，遑论还有中间人攻击呢（不知道说的对不对，印象中是这个）；
- 第一点不是建议用户使用相同的用户名密码，而是从服务安全设计的角度出发，尽最大努力保证用户的信息安全。
第 2 条附言 · 182 天前
感谢大家的回复和讨论，说的都很好，各有观点，非常感谢 45 楼给出的密码强度的例子。
那些直接开喷的还是麻烦省省时间和铜币吧。
如果给出具体的例子来说明好处和坏处，可以让我这种“逆天的”“无常识的”人学到新知识，那么真的感谢你们：诚意+感谢铜币
那些直接开喷的还是麻烦省省时间和铜币吧。
如果给出具体的例子来说明好处和坏处，可以让我这种“逆天的”“无常识的”人学到新知识，那么真的感谢你们：诚意+感谢铜币
第 3 条附言 · 182 天前
此贴完结，至少与我而言是结束了。
感谢举例论证和指出我的错误的 v 友，使我认识到错误之处也学到了新的东西，已发送感谢。
总结如下：
错误：
1. 认为 https 的传输通道是不安全，可以比较容易破解的；
2. 论证前端加盐 hash 时使用拖库作为论据；
3. 其他。
更新知识库：
1. https 是安全的传输通道；
2. 二因素验证是防止拖库的有效手段。
另外，如果“吸词”的作者看到，请忽略第一点，有空的话考虑修复一下每个网站都会发送登录验证请求的问题吧。
最后，在以后的设计中还会考虑前端 hash 密码，以达到“密码明文在整个流程中不应该被其他人或应用所感知”的目的。
感谢举例论证和指出我的错误的 v 友，使我认识到错误之处也学到了新的东西，已发送感谢。
总结如下：
错误：
1. 认为 https 的传输通道是不安全，可以比较容易破解的；
2. 论证前端加盐 hash 时使用拖库作为论据；
3. 其他。
更新知识库：
1. https 是安全的传输通道；
2. 二因素验证是防止拖库的有效手段。
另外，如果“吸词”的作者看到，请忽略第一点，有空的话考虑修复一下每个网站都会发送登录验证请求的问题吧。
最后，在以后的设计中还会考虑前端 hash 密码，以达到“密码明文在整个流程中不应该被其他人或应用所感知”的目的。
109 条回复 • 2024-05-26 14:57:40 +08:00
 |
101
leafin 181 天前
恕我直言，你连网站服务器都不信任了，却又在不同网站使用相同密码？
就好像你把车借给不信任的人开，却把车钥匙和家门钥匙一起给出去一样好笑。 如果这是题主的真实需求，那我对题主是否真的在乎安全表示怀疑，如果这不是题主的真实需求，那我只能说醒醒吧别做梦了 安全必须由自己负责 |
 |
103
carpeDiemJll 181 天前
@mark2025 #84 [globalsalt 的目的是即便用户在不同网站输入的相同口令，也不会有相同的 pass1] 这句话没太懂，你既然全局使用一个全局固定盐 globalsalt ，那么生成的 pass1 怎么可能不一样呢？ 这里的不同网站，其后端也也不一样吧？
|
 |
104
XiaoXiaoMagician 181 天前
一路看下来，我觉得前端 hash 唯一有用的目的在于防内鬼，要么防内部技术人员搞恶趣味的东西。
现在部分公司有前端 hash 的逻辑大概率就是我上面说的，要么就是 http 的历史遗留产物仅此而已。 |
 |
105
Wy4q3489O1z996QO 181 天前
来个 AI 简要的解读一下这个帖子的进展和讨论走向
|
 |
106
Jirajine 181 天前
@BeautifulSoap 所以你偏题了，这里讨论的不是不信任中间件，而是不信任服务端，中间件的攻击面只是服务端不被信任的原因之一。
后端不应该能够得知密码原文因为后端不需要得知密码原文也能实现完整的功能。而前端多进行一步加盐 hash ，也就是不让后端得知不需要的隐私信息的行为，你称之为“没有开发经验，连基本 it 知识和安全思维的没有的逆天”。 |
 |
107
mark2025 181 天前
@carpeDiemJll 意义在于假如你的通用密码是固定的，那么采用相同散列算法（比如 md5 ）的结果一定是相同的。如果是添加了全局盐生成的，那么至少我这儿的值和其他地方不一样。那么如果这儿被拖库拿到你的密文（比如 md5(pass+globalsalt ），也无法简单通过社工获得你的明文口令。
|
|
108
carpeDiemJll 180 天前
@mark2025 #107 我明白。后面的 [也无法简单通过社工获得你的明文口令] ，我的疑虑是 [如果是添加了全局盐生成的，那么至少我这儿的值和其他地方不一样] ，盐是全局相同的，那么 md5(pass+globalsalt ）怎么可能不一样呢？这里的全局说的是一个系统的全局吧？比如 V2EX 有一个全局盐，知乎有个全局盐，它俩不一样。
|
|
109
mark2025 179 天前
@carpeDiemJll 是的，假定是大家都使用各自的全局盐（以及算法），来保证即便是相同的明文入库的密文也是不同的。其实大家登录密文算法都不一样，这个办法主要是确保”自己“网站被拖库后不会被简单解算出明文从而殃及用户在其它网站的账号。属于自律行为。
|
Select Language