JavaScript不能安全加密密码，因前端代码完全暴露，任何加密逻辑均可被反编译或绕过；安全核心必须依赖后端用bcrypt或Argon2等强算法进行不可逆哈希。

JavaScript 本身不能安全地“加密”密码，真正安全的做法是在前端做哈希加盐处理（仅作预校验或辅助），但核心必须依赖后端用强算法（如 bcrypt、Argon2）完成不可逆哈希。浏览器环境无法保证密钥或算法逻辑不被窥探，直接在前端“加密”容易误导开发者，反而降低安全性。

为什么不能在前端用 JavaScript 加密密码？

前端代码完全暴露在用户浏览器中，任何所谓“加密”逻辑（比如用 CryptoJS 做 AES）都可被轻易反编译、调试绕过。攻击者能直接获取原始密码，或替换你的加密函数为恒等函数。更危险的是，若你把密钥硬编码在 JS 里，等于把锁的钥匙贴在门上。

• HTTPS 只保护传输过程，不保护前端逻辑安全
• Base64、MD5、SHA-1、SHA-256 等哈希都不是密码哈希——它们太快，易被暴力破解或查表攻击
• Web Crypto API（如 SubtleCrypto）虽支持 SHA-256/SHA-512，但仍缺乏加盐、自适应迭代等关键防护，不能替代 bcrypt/Argon2

前端该做什么？——合理使用 Web Crypto 做轻量预处理

可在提交前用 SubtleCrypto.digest() 对密码+随机盐（由后端生成并返回）做一次 SHA-256 哈希，作为传输摘要（非存储用）。这能防止明文密码意外暴露在日志或中间代理中，但绝不替代后端密码哈希。

• 示例：用 Web Crypto 计算密码摘要（仅示意，盐必须由后端动态下发）

async function hashPassword(password, salt) {
  const encoder = new TextEncoder();
  const data = encoder.encode(password + salt);
  const hash = await crypto.subtle.digest('SHA-256', data);
  return Array.from(new Uint8Array(hash))
    .map(b => b.toString(16).padStart(2, '0'))
    .join('');
}

⚠️ 注意：盐不能写死，也不能由前端生成后直接发给后端——否则攻击者可重放该盐发起离线爆破。真实场景中，盐应由后端在登录请求时随 challenge 一并下发，且单次有效。

后端才是密码安全的核心防线

所有密码必须在服务端用专用密码哈希函数处理：

• 推荐 Argon2id（内存与时间可调，抗 GPU/ASIC 破解）
• 次选 bcrypt（成熟稳定，自动加盐，迭代轮数可调）
• 避免 PBKDF2（虽比 SHA 安全，但参数配置不当仍易受硬件加速攻击）
• 绝对禁用 MD5、SHA-1、无盐 SHA-256 存储密码

例如 Node.js 中使用 bcrypt：

// 注册时
const saltRounds = 12;
const hash = await bcrypt.hash(password, saltRounds);

// 登录时
const isValid = await bcrypt.compare(inputPassword, storedHash);

其他关键安全实践

• 始终启用 HTTPS，防止密码在传输中被截获
• 密码输入框设置 type="password" 并禁用 autocomplete（autocomplete="new-password"）
• 限制登录失败次数，引入验证码或临时锁定机制防暴力破解
• 敏感操作（如改密、转账）要求二次验证（短信/邮箱/TOTP）
• 定期审计密码策略：强制最小长度、禁止常见弱口令（可用 zxcvbn 库前端校验）