登录接口明文密码在浏览器端先加盐 SHA512 一次，服务端再用 bcrypt 等慢哈希算法二次加密存储是最佳实践吗？为什么多个大厂都发生过不小心在日志输出用户明文密码的事件，不加密或可逆加密传输用户密码仍是主流

登录接口

加盐

Bcrypt

47 条回复 • 2025-09-09 17:11:02 +08:00

1

2wex

10 小时 28 分钟前

互联网企业搞安全成本高收益小，除非监管强制要求，否则能省就省

2

abc612008

10 小时 3 分钟前 via Android

没法判断密码是否符合复杂度要求吧，大小写特殊符号之类的

3

hyperbin

9 小时 54 分钟前 via Android

因为就算泄露了没人追责，也没有天价罚款，所以无人在乎

4

seth19960929

9 小时 11 分钟前

你说得对，bcrypt 能解决密码问题，但是你架不住历史包袱久，重构账户相关出事了一锅端
只要不重构禁不住有人打印整个模型，模型有自带解密方法
至于你说的检测规则，都已经加密传输了，直接从前端检测就好了，还检验什么😂前端搞坑多
所以还是后端哈希，片段 HTTPS 就行了，至于密码的事，后端的问题自己解决，工程化的工程化，不然下次没课密码，还有身份证，手机号

5

yy306525121

9 小时 10 分钟前 via iPhone

我们都是直接对称加密或者非对称加密，到后端再解密

6

codehz

9 小时 2 分钟前 via Android

1

零知识证明不就可以了？😓比如 telegram 用的 srp 协议和更通用的 pake 协议，只要保证客户端没人篡改，就没人可以解密原始密码，服务器也不知道

7

xuanbg

8 小时 43 分钟前

服务器本来就不应该知道用户的密码是什么。严格来说，就是明文密码不出客户端。只要这个密码离开客户端，就要用摘要算法计算 hash 值代替。

另外，加密传密码是什么鬼？你拿用户的密码想干什么？

8

Lexgni

8 小时 37 分钟前

@xuanbg 只传摘要，那设置密码也穿摘要吗

9

xuanbg

8 小时 35 分钟前

@Lexgni 当然啦，通过别的方式而非密码验证用户身份的合法性，譬如短信验证码。

10

wangtian2020

8 小时 35 分钟前

你是老板还是打工的，加密差不多够用就得了

11

evill

8 小时 31 分钟前

不是这种方式有什么难度，也不是这样做有什么成本

而是做的某种程度(特别是 toC)有人会要你明文保存，但是没文件没规定
最搞笑的是这个和等保还是冲突的

12

selca

8 小时 31 分钟前

前端判断强度就完事儿，你硬要用接口突破安全行为，设置弱密码，我这儿也看不到密码原文。

实在要全链路安全，还得设计类似 tls 的公私钥握手过程。

13

darkengine

8 小时 31 分钟前

先问是不是，有哪些“多个大厂都发生过不小心在日志输出用户明文密码的事件”？

14

ladypxy

8 小时 30 分钟前

前端加密本身就是脱裤子放屁的事，都有 https 了前端加密的意义是什么

15

superrichman

8 小时 21 分钟前

@ladypxy https 是防传输过程泄密，前端哈希可以防止在传输目的地的服务端泄密，两者并不冲突。

16

capric

8 小时 14 分钟前

1

用 opaque
https://github.com/facebook/opaque-ke

17

yb2313

8 小时 13 分钟前

为什么要在前端加盐, 如果会被截取, 人家直接拿加盐后的密码当密码用不就行了吗? 如果不会被截取, 那直接明文传输在后端加盐哈希存储才对吧?

18

totoro52

8 小时 13 分钟前

《大厂都发生过不小心在日志输出用户明文密码的事件》
没听说，至少我不会把用户登录信息输出到 log 上，没啥意义也不必要这么做

19

bfdh

8 小时 12 分钟前

@xuanbg #7 "加密传密码是什么鬼？你拿用户的密码想干什么？"
1 、客户需求，而且这个客户还不听劝；
2 、有些软件就是需要明文密码，比如 pppoe-server 、svn server 、ftp server ，虽然有些可以结合其他软件使用非明文密码，但简单实现都是基于明文的。

20

way2create

7 小时 59 分钟前

1

不前端加密新项目都是直接 https+bcrypt 旧项目懒得管他们怎么写我用啥不操心这些

如果还需要加强安全措施不都是二次验证之类的

至于前端加密，B 站那些卖课的就喜欢搞这些

另外如果一个项目日志会泄露这些。。。那估计我想就不单单是密码的问题了

21

loading

7 小时 47 分钟前 via Android

我有个项目就是的在前端加盐 hash 后给后端的，密码强度验证就只在前端，后端只收到 hash 结果。

22

shunia

7 小时 33 分钟前

1

前端加密也好，hash 也好，作用是什么？完全没看懂。

我只能想到一个作用，就是拿这个特定的用户名和密码组合来做碰撞攻击其他服务/工具。

23

shenjinpeng

7 小时 21 分钟前

1

服务器端有一百种方式泄露用户密码, 例如 nginx 日志, 网关层, 框架日志, 接口请求记录, 中间各层 HTTP 请求,RPC 请求 ... 不管怎么样, 从服务器接收到请求开始,再到用户中心给密码加密之前, 所有中间层能可以明文看到用户密码 .

24

zzsong

7 小时 6 分钟前

没明白前端 hash 的意义在哪，对与服务端而言密码不就变成了前端 hash 后的值了吗？非但没有提升安全性，反而增加了碰撞的可能性。

25

catamaran

7 小时 4 分钟前

1. 谈不上最佳实践，bcrypt 加密没啥争议，java 的主流做法。至于浏览器端加密，满足客户要求就好，最多的场景就是浏览器提交的密码不是明文就行。浏览器端加密本身争议就比较大，没必要非得求个定论。
2. 密码泄漏我有印象的，一个是 csdn 被拖库，因为用明文存储的，另外一个是阿里云的事情，细节不记得了，原因是把 secretkey 写到了代码里，然后传到了 github 上。没听说过日志泄漏的。这种只能说开发也太没有安全意识了，敏感信息不该进日志。

26

catamaran

7 小时 1 分钟前

@shenjinpeng 都能进入中间层了，明文密文还有意义吗？反正后端认就能利用。

27

Building

6 小时 55 分钟前

第一 https 都被挟持了你做再多的加密都没用了
第二密码可以携带多重信息的，比如可以在密码后面加验证码可以让老版本没有验证框的也能登陆

28

nekoneko

6 小时 29 分钟前

其实没意义. 前端明文 + https + bcrypt 即可. 至于 https 被劫持和后端流程泄漏密码, 这是另外的问题.

29

restkhz

6 小时 15 分钟前

有很多人说前端 hash 是为了防止服务器沦陷，比如服务器流量干脆被劫持，TLS 证书被盗。
“服务端不可信任！”
但是如果是 web 的话，入站流量里的密码能被劫持所以你 hash 了用户密码，思路 OK 。
但是如果服务器已经沦陷，别人不能直接改你出站流量里前端 js 脚本吗？直接去掉 js 里 hash 步骤让用户明文提交，或者干脆就钓鱼，咋办？
或许你做的是 APP 的 API 吧，不从服务器接收认证逻辑，我不否认这是一种纵深防御思想...

我对此的态度是，反正没有太大收益，只要不怎么增加复杂性，开心就好。

因为信任 TLS ，信任服务端。我想这就是不 hash 提交密码的原因。
否则服务端若不可信任，你大概要再做一套认证+加密，几乎就是再发明一个 TLS 了。

所以我也不太清楚，TLS 后，前端流量还要加密一下的意义有多大，我见过有用 AES 的(对，还不是非对称)，甚至比前端 TLS+hash 还难理解它的意义。

不恰当的比喻：TLS 都能被攻破的情况下，你再加一层凯撒位移不会更安全。
制造无意义的信任边界，过度设计只会让事情变得复杂，增加成本，甚至可能更不安全。

btw ，什么是“可逆加密”？不可逆的加密是加密吗？（小声）

30

lambdaq

6 小时 3 分钟前

明文密码不一定是泄漏，还可能是试出来的。

31

ala2008

6 小时 2 分钟前

我们会对敏感数据做非对称加密再传输

32

Hozoy

6 小时 1 分钟前

Google 登录至今还是传输的明文密码，Twitter 也发生过明文密码记录到 log 的安全事故。所以明文传输密码本身并没有什么问题，只要后续链路存储规范即可。

33

ladypxy

5 小时 57 分钟前

@superrichman 你服务器都能泄密了，你啥加密都没意义了

34

superrichman

5 小时 47 分钟前

@yb2313 盐即使泄露，问题通常也不大。盐的主要目标是防止相同密码产生相同哈希，以及抵御彩虹表攻击。只要每个用户、每条记录的盐都不同，这样即使攻击者拿到所有盐和哈希，也不能用一个统一的预计算表（彩虹表）去快速破解。

@ladypxy 服务器泄密，接收的和存储的是哈希过的信息，不会泄露原始信息，怎么会没有意义。

加密/哈希的意义就是“把泄露变得不等于彻底泄露”，降低风险，增加攻击者成本。

35

yulon

5 小时 1 分钟前

楼上那么多人连 hash 不是加密都不知道，笑不活了。

难得 LZ 那么有责任心来问一下，结果钓出那么多卧龙凤雏。

明文密码泄漏，是怕你用密码拿去尝试登陆别的网站，不只是泄漏密码的这一家网站的事情。

36

irrigate2554

4 小时 31 分钟前

用密码管理器的表示没关系，你安全做的不好泄漏也影响不到我其它网站

37

ZhiyuanLin

4 小时 30 分钟前

2

这个问题叫 ZKPP （ zero-knowledge password proof ），已经有非常成熟的方案例如楼上提到的 SRP ，PAKE 。
码农不要自己用半吊子的密码学知识拍脑袋想方案，真要安全就用已经标准化的 scheme 。
不过互联网企业大部分属于是能 hash 一下已经是业界领先的水平。

38

BaiLinfeng

4 小时 8 分钟前

我怎么没看懂这是在说啥哦

39

ladypxy

3 小时 47 分钟前

@superrichman 服务器泄密，接收的和存储的是哈希过的信息。你服务器登录啥的用的都是哈希过的信息了，不是院士信息，那你这些信息泄漏了别人完全可以伪造登录了。那你的意义在哪里？

40

way2create

3 小时 46 分钟前

@yulon 没什么别的意思单纯好奇一下你说的楼上那么多人是谁呢我咋没看到有很多求科普
除了一个说 bcrypt 加密的很多 v 友提到加密不都是针对 op 最后一句话问的“为什么不加密传输仍是主流”回的吗

41

superrichman

3 小时 23 分钟前

@ladypxy 哈希的意义在于保护原始密码，从而避免更大范围的损失。保护了用户在其他平台上的安全，不至于“一处泄露，处处沦陷”。

如果服务器直接保存明文密码，一旦泄露，攻击者不仅能直接登录这个系统，还能尝试用相同的密码去撞库或者了解你的密码设置习惯，攻击你的邮箱、社交媒体、支付账户等更高价值的服务。

而保存的是哈希值时，攻击者手里拿到的并不是密码本身，而是需要通过暴力破解手段反推，成本和难度大大提高。