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

[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

关于前端是否应该对密码hash后传输的观点：

1. 密码加盐（每个网站的盐一般都不同）后hash传输，服务端存储的是与原明文密码没有任何逆向关系的字符串，所以即使多个网站使用相同的密码，也不会受到某个网站被脱裤后的影响；
2. 基于第一点，HTTPS是否是加密传输其实无所谓的，与密码的安全并无关系，遑论还有中间人攻击呢（不知道说的对不对，印象中是这个）；
3. 第一点不是建议用户使用相同的用户名密码，而是从服务安全设计的角度出发，尽最大努力保证用户的信息安全。

感谢大家的回复和讨论，说的都很好，各有观点，非常感谢 45 楼给出的密码强度的例子。
那些直接开喷的还是麻烦省省时间和铜币吧。
如果给出具体的例子来说明好处和坏处，可以让我这种“逆天的”“无常识的”人学到新知识，那么真的感谢你们：诚意+感谢铜币

此贴完结，至少与我而言是结束了。
感谢举例论证和指出我的错误的 v 友，使我认识到错误之处也学到了新的东西，已发送感谢。

总结如下：
错误：
1. 认为 https 的传输通道是不安全，可以比较容易破解的；
2. 论证前端加盐 hash 时使用拖库作为论据；
3. 其他。
更新知识库：
1. https 是安全的传输通道；
2. 二因素验证是防止拖库的有效手段。

另外，如果“吸词”的作者看到，请忽略第一点，有空的话考虑修复一下每个网站都会发送登录验证请求的问题吧。

最后，在以后的设计中还会考虑前端 hash 密码，以达到“密码明文在整个流程中不应该被其他人或应用所感知”的目的。

[FTLIKON]

其实密码明文传输还挺常见的，GitHub 的注册登录就是明文传输密码

[YogiLiu]

明文传输其实很常见，和是否泄漏没啥必然联系，加上协议用的是 HTTPS ，基本上没什么关系；我比较好奇第二个问题。

意思是这个插件会把你在每个网站的帐号传输到某个 URL ？如果是这样，那这不就是木马吗？

如果你想表达的是这个插件每到一个新的网站就会把你的「吸词」账户信息发给这个 URL ，那我觉得可能是作者比较懒，不想做 Token 认证，当然这样把用户密码明文持久化在浏览器相对来说是不安全的。

[javalaw2010]

不考虑这个请求本身的合理性。我也不认为基于 https 的密码明文传输有什么问题。

[povsister]

https 的 body 明文不是问题，密码编码更多时候是为了避免奇怪的字符导致问题。
我更关心它为什么带你的密码，这个插件要登陆？你注册了账号？
你账号密码多个平台通用一套？

[grit136907108]

> 回复上面的
安装了这个插件试了下，每打开个网站都会请求这个插件的登录接口，不是说会把你其他的账号密码带进去

[zero47]

确保是 Https 其实没什么问题，当然你要是投诉他确实可以让他下架整改，因为相关法律法规对这方面还是有要求的

[Jirajine]

> 为什么密码要明文传输？
因为太多人认为密码明文传输不是问题。如果你不为这些人开发的服务使用密码管理器生成全随机的专用密码，那你就是受害者。

[YogiLiu]

其实我能想到密码编码后传输还有一个场景，现在很多大型 Web 服务都用上了微服务，HTTPS 只能保浏览器都入口网关的安全，到了应用层或者微服务之间的传输，万一一个不小心把 Payload 泄漏出来（比如打到了日志里），加之很多用户喜欢一套账户密码走天下，很容易被撞库，所以即使是简单的哈希一下，也可以稍微强化一下这方面的安全性。

[lisongeee]

你对 [密码明文传输] 认知有点像 https://v2ex.com/t/984105

[belin520]

https 传输就是加密的呀

[rambo92]

@FTLIKON
@YogiLiu
@javalaw2010
@povsister
@zero47
个人不赞同 https 就可以明文传输密码的观点。
从我 14 年入行时就接受了密码必须 MD5(加盐更好)后传输，服务端也不存明文密码，防止被脱裤的观点。


@YogiLiu 是的 第二个，“如果你想表达的是这个插件每到一个新的网站就会把你的「吸词」账户信息发给这个 URL ”


@povsister 非重要网站一般是通用一套


@Jirajine 确实，难以认同 HTTPS 就能明文传输的合理性

[maggch97]

@rambo92 绝大部分插件安全性都堪忧，都有非常多可利用的漏洞。

在意安全其实一个插件都不应该装。

[xiaoming1992]

我认为“密码明文传输也安全”必须有一个前提是放在 https post 请求的 request body 里，直接放在 url 请求参数里怎么也不能称之为安全。

[ersic]

@rambo92 大部分网站都是明文呀，包括你现在用的 v2

[xiaoming1992]

非要放在 url 里，那应该是 token

[mohumohu]

《 https 》《明文》
v2 日经:https://www.v2ex.com/t/1025454

[YogiLiu]

@xiaoming1992 Path / Query / Headers 在 HTTPS 加密是都是在加密体里的，它们和 Body 的距离只有两个空行。

[kera0a]

@xiaoming1992 url 参数也是 https 加密的范围，和放 body 里没有啥区别

[Alander]

@lisongeee 居然当时错过了这个帖子，看完内容，黑人问号 哈哈

[xiaoming1992]

@YogiLiu @kera0a 好吧，那是我孤陋寡闻了

[FTLIKON]

@rambo92 MD5 摘要算法不是加密算法.

[june4]

都 https 了，再加个密简单多此一举，除非你认为 https 可破解。
如果是本机被木马，那加个 md5 也防不了，浏览器插件都可以读取 html 页面，完全可以监测到 html 里的 password 控件并直接取里面的密码回传，加密加了个寂寞。

[povsister]

@mohumohu #16 谢谢，承包我今天的笑点

[rambo92]

@FTLIKON 我没说过 MD5 是加密算法啊。

[FTLIKON]

@mohumohu 还真是，我发现每隔一段时间这个问题就会蹦出来讨论，看来这个问题已经是小白判断器了

[bertonzh]

@kera0a 真正搞过后端服务的都知道，放 URL 跟放 body 差别太大了。
放 URL 里面，你的密码会被保存到 N 个日志库里面。

[InkStone]

其实关于 https 传输明文密码这个问题，答案是很确定的。

它肯定没有传输加盐哈希安全，但对于 99%的情况足够安全。

当然，1%并不是一个很低的概率，所以现实中我们也可以看到因为明文传输、存储密码导致的大规模安全问题已经发生很多次了。

[d7101120120]

在没有中间人攻击的情况下，从外部抓包是无法获取到 https 请求的 url 的参数的，至于这样做是否合适其实也没有统一的标准。

[FTLIKON]

@Jirajine 你的观点只使用于 http 的网络请求，除非您认为 https 是可以破解的

[mohumohu]

我觉得 OP 可以换个更有力的标题：
请 Google 出来解释一下密码明文传输的问题
请 Github 出来解释一下密码明文传输的问题

[hefish]

这个。。。 [吸词] 这个是干啥用的东西？

[rambo92]

@mohumohu 本帖的第二个问题被忽略了，大家都在讨论明文传输的问题


@june4 前端可以扩展到 Web 、iOS 、Android 等等

[InkStone]

@FTLIKON 因为证书误用导致的 https 破解其实并不罕见。

其实就算证书没误用，如果 ciphersuite 配的不对，也完全有可能被破解（不过说实话现实中没见过类似的攻击案例，只在 PoC 中见过）

[milzero]

@mohumohu #30 Github：爱用用，不用滚！！！

[zero47]

@rambo92 明文入库确实是该死的，但明文传输不代表明文入库，不明文入库应该是每个程序员的基本素养吧。很多项目早些年因为多端，所以都会在服务端才做摘要。要是严格按照法律法规的话，不单单是密码，手机地址身份证都是要加密传输的

[bertonzh]

@YogiLiu 对的，放 Payload 或者 header 里面还好。如果放 URL 参数里面，又没有专门处理过（自动识别敏感字段并打码），搁任何大公司，百分百会被记录到日志里面，百分百会被安全拉高危工单。

[rambo92]

@mohumohu 挺有意思的，如果 Google 和 GitHub 也认为明文传输是合适的，那你们对；
而我坚持自己的观点。

[bertonzh]

如果所有网站都用同一个密码，这就是一个木桶问题，你无法保证所有网站所有环节都是安全的。
所以还是用唯一密码吧。

[Trim21]

你不跳校验不乱加根证书怎么会有中间人攻击的问题？

顺便，github 还真是在 https 下明文传输密码的。#16 发的帖子里的讨论你是一点都没看。

https://www.v2ex.com/t/1025454#r_14474726

[rambo92]

@zero47 嗯，是的；
不过还有日志打印密码的骚操作。。。 这个素养还真不是每个程序员都有的啊；基于此，那么在架构设计时确定前端 hash 后传输，也可以防止这些情况的发生。

[dode]

我认为 HTTPS 服务，明文密码是正常的行为

[ntedshen]

前端做加盐哈希能防脱裤。。。这理论不亚于戴个贞操锁然后把钥匙别在边上。。。
后端好歹还塞在里面，要先亲密接触一下隔夜饭才能拿出来。。。

不过
https://jnexswpfgysrqlagwajs.supabase.co
这个域名确实写在 1.0.9 版的 crx 安装包的的 chunk-7bd2bbc8.js 里

grant_type=password 请求从属于 signInWithPassword 方法

向上
yr = async (n, e) => {
const {data: t, error: s} = await se.auth.signInWithPassword({email: n, password: e});
t.user && await ze.storage.sync.set({[ye]: {email: n, password: e}}), s && console.error(s);
}
jt = async () => {
const n = await ze.storage.sync.get(ye);
if (!n[ye]) return;
const {email: e, password: t} = n[ye], s = await Ce();
return (!s || s.email !== e) && await yr(e, t), e;
}

继续向上则是
kr = async (n, e = 0) => {
if (!await jt()) return !1;
const s = await Ce();
if (!s || !await Rt()) return !1;
const i = await br(n.name, n.origin, s.id);
if (i && i.length > 0) return !0;
const {error: a} = await se.from("words").insert([{...n, user_id: s.id}]);
return a ? e >= 2 ? !1 : kr(n, e + 1) : !0;
}, Sr = async (n, e = 0) => {
if (!await jt()) return;
const s = await Ce();
if (!s || !await Rt()) return;
const {error: i} = await se.from("words").delete().match({name: n, user_id: s.id});
if (i) {
if (e >= 2) return;
Sr(n, e + 1);
}
}
这个看起来已经是功能模块了
可见问题应当出现在 jt 方法，当 kr 和 Sr 试图保存单词的时候发现没有登录成功或者没有建立对应的数据库，因此自动尝试登录

至于为啥这么蠢别问我。。。反正不是我写的。。。

[abelyao]

恕我直言，在前端给密码套 md5 然后传给后端，简直是傻 X 行为，不是你入行多久就是对的

[rambo92]

@Trim21 没细看，太长了，只看了第一页的一半大概

@dode 嗯，个人观点

@ntedshen 感谢代码分析
另外贞操锁钥匙别外面这个比喻不太恰当，如果仅仅 hash 的话这么说没毛病，毕竟大部分用的 hash 函数都是 md5 ；
而加盐哈希，每个服务的盐不同，相同的密码得到的摘要也不同，更像是每个服务都有自己的贞操锁

[tsanie]

摘要入库是没有任何异议的，但密码通过有保障的通道（ https ）明文到达后端是合理需求，否则后端如何做密码强度验证？

强度验证放到前端做才是真的会有安全问题。

[MrSheng]

@rambo92 #40
你一直说加盐加盐，盐值存在哪里呢？

[ck65]

在 HTTPS 上传明文密码无可指摘

[FTLIKON]

@rambo92 #44 前端加盐 hash ，你加的盐遇到个会扒你前端源码的不是分分钟就被破解了吗？

[Goooooos]

客户端 hash 后传给服务端，其实被人拿到 hash 后的密码也可以直接登录
跟传明文没差别，好处就是如果这个人多个网站用同一个用户名和密码可以减少其他网站被牵连，还有这么点用

[rambo92]

@abelyao 无论你的还是我的，都是个人观点，可以给出论据来讨论，直接傻叉的话这话并没有分量。

我入行才 9 年多，也不算久，说 14 年入行也不是为了说明自己资历老就是对的，而是说明一下刚入行的时候就接受了这个观点的影响

[javalaw2010]

我本身是不想参与 V2 这种月经贴的讨论的，不过今天实在是太闲了，秉持着真理越辩越明的理论，我还是想再多理论两句。
> 密码加盐（每个网站的盐一般都不同）后 hash 传输，服务端存储的是与原明文密码没有任何逆向关系的字符串，所以即使多个网站使用相同的密码，也不会受到某个网站被脱裤后的影响

其实稍有编程常识的后端开发都会选择加密入库，不可能有人选择加密入库的。不过我们假设就有这样一个刚入行的愣头青，写了个明文入库的代码，好巧不巧，他被拖库了。黑客拿到了份数据库，得到了一个（ xiaoming, password123 ）的账户名和密码，他想使这样一个用户名密码来登录一个前端加密网站，此时他选择了最简单的办法，手动输入，他在用户名输入框里输入了 xiaoming ，在密码框里输入了 password123 ，而当时小明也在该网站输入了同样的用户名和密码，此时黑客点击登录，那么你觉得他是能登进去呢，还是不能呢？

> 基于第一点，HTTPS 是否是加密传输其实无所谓的，与密码的安全并无关系，遑论还有中间人攻击呢（不知道说的对不对，印象中是这个）
我不太明白是什么可以得出了 HTTPS 和密码的安全无关这样一个结论的，而中间人攻击，你的网站/APP/操作系统必须信任一个原则上不可信的第三方证书，中间人攻击才能得以实施。这意味着要么你主动信任了一个不可信的中间人，要么黑客得到了你的操作系统的控制权。而中间人攻击一旦得以成功实施，经过前端加密的密码，也不过是变成了另一个密码的明文而已。

实际上，要真正解决密码被拖库的碰撞问题，要使用的解决方案是二因素认证，而不是前端加密。

[kads]

首先，装不安全的插件本来身就是不安全的。明文有可能泄露的风险，但是极小概率的。在你网站输入的时候，更容易获取的你的密码而不需要中间人攻击，这个攻击也很难实现，需要证书。在前端无法保证传输的安全，只能在后端加密保存。即使他们不知道的密码 也可以重放攻击

[BeautifulSoap]

真的是叹为观止，这就是不光没有开发经验，连基本 it 知识和安全思维的没有的人的反应。提出的前端加盐 hash 更是逆天

[dcsuibian]

前端哈希主要是防止后端不小心在日志中把密码打出来

[MorJS]

前端加密✌️=放屁

[abelyao]

@rambo92 我并没有想提供很多论据跟你讨论谁对谁错谁更有说服力，无论是理由还是相关讨论在 V2 在互联网都有很多，你愿不愿意接受这个事实都是你的事，我只是纯粹说这个行为是傻叉行为，你愿意继续 hash 就继续 hash ，没有要说服你或非要你能理解的想法

[cnevil]

https 就相当于是加密了。。你再加一次有什么用呢
前端对字符串加密跟明文没任何区别，如果我能从你 https 里获取到了原始的请求体内容，依旧可以用这个加密后的字符串进行重放，这个加密后的密文就等于你的明文密码，不知道你能不能想明白这个道理
除非你每次登录都重新生成一对密钥

[rambo92]

我的“前端需要 hash 传输密码”的观点，是建立在传输通道不安全（非源头，如 web 、iOS 等）的前提下，因为当时使用 http 的服务还有不少，加盐 hash 是为了防止传输通道被入侵时拿到明文密码；而在 https 是安全且极难入侵的传输通道的前提下，那我的观点的前提就不成立了。感谢普及 https 安全性的 v 友。

此外我有个问题希望和大家讨论一下：
密码是否应该在整个服务的流转过程中都是安全且不可接触的呢？
换句话说，如果服务端接收且打印了（或其他形式）明文密码，而这个信息可以被普通权限的开发者或员工接触到的话，作为用户是否可以接受呢？

[jianchang512]

一般前端想 hash 密码，多是防止这 2 个问题吧

1. https 传输过程中泄露，加密后即使泄露也不会被看到真实密码
2. 后端可能会将请求信息打入日志，如果未加密可能会出现直接密码明文显示在日志里



前端 hash 防的从来不是脱裤，没有哪个后端会直接明文存入密码吧，至少得一层 md5 吧，如果被脱裤明文泄露，问题也是后端，和前端毫不相干。

[rambo92]

@javalaw2010 感谢讨论。
这两点都是建立在传输通道不安全的基础上得出的结论，就是不光 http 不安全，也不放心 https 的安全性，认为都有可能被入侵而拿到传输的密码明文。
既然大家都认同 https 是安全且极难入侵的，那么我的观点的前提就不成立了。

第一个问题：能登陆，都拿到明文密码了，反过来就不行了（这也是 hash 存储的目的）；而前端 hash 的目的是防止在传输通道拿到明文，我前面说的脱裤的例子是错误的，无法证明这个手段和目的的合理性。

[rambo92]

@jianchang512 是的，脱裤的例子不对

[catamaran]

@rambo92 打印密码？你看 linux/mysql 登录的时候密码根本都不回显，mysql 涉及用户操作的一些语句也不会保存在命令历史中。除了用户自己，任何人都不应该能接触到明文密码。

[oneisall8955]

月经贴

[0xC000009F]

@MorJS 做过几个银行的项目，都要求前端用加密机加密。

[yuhaofe]

@0xC000009F 是的，前端代码加密混淆和传输数据非对称加密等是有意义的，不过感觉重点不在于安全上，更像是用来加大逆向难度防脚本的

[rocmax]

担心刮大风把山吹走，解决方法是在山上加一把土。

[Jirajine]

@FTLIKON
@tsanie
@BeautifulSoap
是的，后端能够得知密码原文是合理的需求，前端加盐 hash 都是逆天。因为这样我可以在哪天倒闭跑路之后把用户的用户名和密码 dump 出来卖给黑客拿去撞库。哦，如果哪个用户跟我 dispute ，我可以直接拿他的用户名密码去其他网站登陆他的帐号给他开盒。

或者你相信任何人都不会做这样的事情？

[BeautifulSoap]

@Jirajine 大聪明，有没有一种可能，只要是脑子正常的的后端程序员，都不会明文把密码存到数据库里去？
当然你可以死鸭子嘴硬说有的网站就是要拿你明文密码去卖钱，那么有没有另一个可能性，真有网站目的是这个的话，它有一万种方法变相搞到你地明文密码？

[giiiiiithub]

1. 我觉得这类帖子只有安全专业的同学的回答具有参考意义，但是目前好像没看到有安全专业的同学来讲讲。搞开发的可以说说自己的见解，但盲目自信的感觉还是不要秀了。

2. 只讨论 https 环境，不问缘由，可以参考大厂是怎么做的。当然大家贴出来的大厂答案既有前端加密也有前端不加密的。

[Jirajine]

@BeautifulSoap 有没有一种可能，我只是一个负责中间件/负载均衡或者其他什么根本不需要接触数据库的组件的开发，我发现某个组件有 bug ，于是就加了几条 log 把部分请求打到日志里。回头我把这些日志收集清洗一下，我就掌握了大量用户的密码了。

或者你认为任何公司的任何员工都做不到/不会做这样的事情？

有没有一种可能，那一万种变相搞到你明文密码的方式，其实都是一种：以后端能够得知原文的方式传输密码。

[lesismal]

@FTLIKON #1
github 的问题也不是没被暴出来过，类似 @YogiLiu #8 说的问题：
https://zhuanlan.zhihu.com/p/36603247

单就传输信道而言，https 能解决中间人问题，明文在这个用户前端到厂商之间的 https 信道范围内没问题。
单就 github 而言，因为有二次验证，所以即使拿到密码了换个设备也登陆不上，所以有一定合理性。但 v 站没有二次验证，用明文我个人观点不太赞成 @Livid

安全不只是传输信道，传输信道中间人之外还有社工、复杂的人生场景，例如有人借用你电脑的时候给你设置了个代理或者装了马拿到了你的帐号密码，以后说不定做什么坏事，这就属于传输信道之外的安全场景了。

用了 https 就明文只解决信道安全问题，用明文至少意味着：
1. 用户应该尽量管理好自己设备的安全
2. 用户到厂商之间的 https 信道之外的处理流程上，厂商应该确保安全，例如上面引用的文章里提到的 github 爆出来的问题以及 @YogiLiu #8 说的问题

另外更简单的一个思考，如果不用明文、我们实现上增加了什么成本，带来了收益，有什么损失？
1. 成本：几乎没有增加额外成本
2. 收益：安全强度提高了
3. 损失：安全上没损失，但厂商不知道你明文，至于厂商知道你明文有什么好处，自己脑补吧

[crab]

@kera0a 有的浏览器会收集 url 的 get 请求

[BeautifulSoap]

@Jirajine
有没有可能，中间件往 log 里打印所有请求体以及返回值这件事，本身就是一个项目中极高等级的重大安全隐患？当一个项目中有组件不分青红皂白把 payload 往 log 里打印的时候你竟然只关心密码？你所有的个人信息，姓名，住址，银行卡号，令牌以及其他关联服务的令牌等等所有一切信息都会被输出到 log 。那么如果按照你的顾虑，为了防止中间件有恶意内部第三者，是不是不光密码不能明文，所有请求内容也要一并加密？

[lesismal]

很多人都是觉得：有人用明文，尤其是有大站例如 github 用明文，所以就是对的，根本没考虑过信道之外的安全，也没有考虑大站是否有额外的安全策略例如二次验证，也没有去统计对比，是不是所有大站都用明文、或者用明文的大站占据绝大多数，也没有去区别不同站的类型和对安全的需求等级，比如是否涉及资金安全的，例如金融类、电商类相关的接口

再用脚想一想，如果 https+明文就安全了，为啥还要有二次验证？

[zhangjiashu2023]

@lesismal 你去设置里是有 2FA 的

[scodec]

大站用了未必是对的。从信息的角度，能提供验证的信息，就无需暴露出更多的信息(登录)。楼上各楼也总结了，服务端的日志，很多 url 的收集插件。我的观点暴露用户的明文密码，非常不专业。

[Jirajine]

@BeautifulSoap 是的，当你提交姓名/住址/银行卡号等个人信息给某个网站的时候，你应该知道你的信息会被任何包括员工在内有权限的人，以任意方式访问/传输/存储/使用/共享，并且你全都无法验证。
这就是为什么要在前端对密码加盐 hash ，使服务端对密码原文保持 zero knowledge 的原因。

[zhangjiashu2023]

事实证明，前端 hash 依然解决不了安全问题，绝对安全还是得上 2FA

[lesismal]

@zhangjiashu2023 #75 看到了，谢谢

[BeautifulSoap]

@Jirajine 等等，谁光跟你说提交了？中间件不光能输出请求体，也能输出 response body 的啊大哥？你的敏感个人信息也是会包含在诸如卡号、姓名、令牌、关联令牌等这些 api 的返回信息里的啊。
lz 你既然这么担心中间件作妖输出提交的信息，那么为什么也不担心一下中间件会同样输出 response body 里的敏感信息？你的顾虑是有道理的，但问题在于我十分不理解为什么你只顾虑密码。按照你的逻辑考虑到这种地步的话，不光请求体里的信息必须加密，所有 api 的 response body 也是必须都要加密的。
而结合 lz 你的帖子和发言，我觉的 lz 你单纯就是经验少连我说的这层都没想到

[lesismal]

@zhangjiashu2023 #78 明文本身也是存在问题的，hash 强于明文，hash+2FA 是强强联合，强强大于强，所以没必要因为有了 2FA 就用明文降级强度

[BeautifulSoap]

@Jirajine 啊，对了。。。有一点差点绕进去导致我说漏了，lz 你再仔细想一想，当中间件真的输出了你的密码请求体，请问这时候输出明文密码还是 hash 加盐之后的密码有非常大区别吗？

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

再说一下，后端密码入库前必须加盐后再 hash 才会更安全这点，原因不在 hash 上，而在于 “盐是保密的” 这一点上。后端的盐除非出了致命漏洞被黑客侵入了服务器内部，一般来说是根本不会泄露的。因为“盐保密”所以这种做法才是安全的。而在前端加盐，这个盐是明文公布给所有用户的，也就是说加盐等于没加。

[mightybruce]

说实话，除了不想让服务端或这个服务商获取信息外需要再次在内容加密外，我真的看不出有必要，也就是端到端加密这种才需要再次对信息内容加密，


密码学本身对于大多数程序员实在太过遥远，这门专业的领域谷歌等大公司在具体业务方面有时候都能爆出问题，就不要说普通程序员的理解了。
有很多算法是根本不需要密码这种体系的，但是成本高实现起来也难，就说几个吧
1.基于身份的加密体系 IBE 可以做到不依赖公钥基础设施 PKI 来保证安全
2. 同态加密， 加密信息搜索以及各种之上的运算能达到明文的效果，可以确保隐私数据没有任何人能看到
3. 谷歌的零信任安全项目 beyondcorp 的系列论文

[mark2025]

@FTLIKON
1. 创建账户/修改密码的时候，后端用一个全局固定盐 globalsalt 与用户口令拼接后使用摘要算法（ md5 ，sha 甚至 pbkdf 等等）入库为 pass1 ；
2. 登录的时候，后端生成随机盐 salt1 ，用户输入的口令与 globalsalt 拼接生成 pass1' ，然后拿 pass1' 与 salt1 拼接摘要生成 pass2
3. 后端收到 pass2 之后，取出 pass1 和 salt1 拼接生成 pass2' ，然后与 pass2 进行比较。

globalsalt 的目的是即便用户在不同网站输入的相同口令，也不会有相同的 pass1

[Jirajine]

@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 的密码是`mypasswordforv2ex.com`，看到明文之后你能不能猜到我在其他网站的密码？更不用说很多人的密码文本本身就包含个人信息，如姓名拼音/生日等。

[mightybruce]

有同学说服务之间调用和日志会暴露信息，可以了解一下服务网格的零信任安全是怎么做的，现在欧美很多大厂要求微服务使用 mTLS 来保证通信安全。

[LnTrx]

关键要讲清楚，前端加密的目的是什么，要防止什么样的攻击/泄露。对于用户侧的攻击，找不要有意义的场景。对于服务侧，因为会有很多环节，加一层防止意外泄露还算有那么点道理。

[tool2dx]

前端用明文密码的最大阻碍，并不是 HTTPS 中间传输的安全性问题。而是后端拿到你明文密码后，公司内鬼会干一些什么。

[LnTrx]

尝试总结一下

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

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

服务端：
服务端的安全性根本在于维护人员的水平。维护人员安全意识淡漠，到处都是漏洞，单单密码加密意义不大。
无论前端有无加密/散列，服务端数据入库都需要再做处理。只依赖前端加盐的安全性还是很有疑问。
在某些特定场景，例如网友说的内部人员打 log 出密码。如果是密文可能懒得研究，如果是明文可能会心生歹意。在这种
情况下，加密也许存在一定意义。

[ShuWei]

有时候，不要过度安全，很多所谓的安全措施其实是掩耳盗铃而已，比如登陆的时候前端先把密码 hash ，都 https 了，不要说什么中间人攻击，既然都能中间人攻击了，先 hash 难道有任何意义？

[LnTrx]

@ShuWei 增加复杂度有时也会降低安全

[jeesk]

加密有多大用处？ 即使你再加密，你电脑不安全，记录你的密码，你也是百搭。 网站的策略默认你的环境是安全的。 你自己用 debug 不也是也能将密码搞出来，然后就演化成对抗了。

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

再举个例子， 文件系统， 磁盘不安全有坏道，那么文件系统是不是强制大家做双硬盘？ 你不是双硬盘我不要让你用？ 反正总有人说磁盘可能要坏，必须双硬盘，否则就是不安全。貌似两种观点都对，但是对于成本和用户体验来说哪个重要？脱裤子放屁的方案太多。

[weijancc]

真是无语, Google 这几年强推 https 就是为了通信安全, 你还搁这"明文传输", 你用开发者工具看看所有主流网站的登录, 密码都是不会加密的.

[hxysnail]

如果 https 能被破解，那么你前端 hash 后传输也没什么鸟用，拿到你的 hash 还不照样黑你？如果 https 不能破解，我传明文又怎样，你还不是拿不到？

换句话讲，在传输过程中，数据安全是由 TLS 加密链接来保证的。当然了，在数据库存储时，必须加盐 hash 或采用其他可靠的加密手段，禁止明文。

[zhw2590582]

不过，chrome 扩展拿到用户密码实在太简单了，而且请求发生在扩展后台里，平常在网页的开发者工具是看不到这个请求的，所以很难让人发现

[GODZZZZZ]

两个问题：
1. 前端加盐后 HASH ，如果每个用户盐不同，盐存在哪？
2. 如何处理密码强度策略变化的问题，前端验证的话，更新前端代码吗？

我一般数据库设计用户表 password 和盐存两个字段，每个用户盐不同，前端原始密码 https 到在后台进行加盐后 HASH 存储到 password 字段，脱裤也没事。

[bitmin]

@GODZZZZZ #96

密码怎么还会自己加盐 HASH 保存，怎么不用类似 bcrypt 去加密

[BeautifulSoap]

@Jirajine so ，你的论点是什么？ 这里讨论的是中间件日志被攻击的场景，以及由此产生的安全隐患。lz 认为密码不能明文传输的最大论据之一就是这个。所以我结合自己的实际项目经历指出了 lz 论据根本站不住这个点，请问哪里偏题了？我的问题和质疑点还是没变，你都不信任中间件了为什么还只关心密码泄露这种小事？

[encro]

是的，将密码明文存储，且不给注销。

[encro]

已联系作者，上次调 api 的时候发现了，打算发个帖，这几天没空，就没发出来。