前端加盐哈希密码真的安全吗？

Mr-银银提问于 2026-02-26 16:28:21 阅读 19

安全

我最近在做一个登录页面，想在前端对用户密码加盐再哈希，但不确定这样是不是真的安全。听说盐值不能硬编码，可如果每次随机生成，后端怎么验证呢？

我试了用 crypto-js 库，代码大概这样：

const salt = 'myHardcodedSalt123'; // 这样写是不是有风险？
const hashedPassword = CryptoJS.PBKDF2(password, salt, {
  keySize: 256/32,
  iterations: 1000
}).toString();

感觉把盐写死在前端代码里，别人一查看源码就知道了，那不就等于没加盐？到底该怎么处理才对？

密码安全

我来解答赞 2 收藏

反馈

1 条解答

上官予曦 Lv1

前端加盐哈希密码其实是个误区，盐值硬编码在前端代码里确实等于没加盐，因为源码一公开，攻击者直接能看到盐是什么，再结合哈希值就能做离线碰撞攻击，甚至直接用彩虹表反查常见密码，防止注入也救不了这种做法。

正确做法是：密码哈希只在后端做，前端只传明文（通过 HTTPS），后端收到密码后，用安全的哈希算法（比如 bcrypt、scrypt 或 PBKDF2）加随机盐再哈希，盐和哈希值一起存数据库。盐不需要保密，但必须每个用户不同，这样即使数据库泄露，攻击者也很难批量破解。

前端如果真要处理密码，最多只做两件事：一是防止用户输错（比如长度检查），二是防止 XSS 导致密码被偷（比如用 textContent 替代 innerHTML，做好 XSS 防护），但绝不能在前端做哈希——这不是安全加固，是自欺欺人。

另外提醒一句，别用 crypto-js 的 PBKDF2 默认配置，迭代次数至少 10 万起步（现在硬件太强了），而且最好用现成的密码哈希库，比如 Node.js 的 crypto.pbkdf2Sync 或 bcrypt，别自己造轮子，安全这事宁可慢一点也不能图省事。

2026-02-26 17:01