17370845950

前端不该用 bcrypt 做密码加密，因其明文密码易被调试器读取、salt 无法安全保管、JS 实现性能差且可被篡改；应仅用 WebCrypto 做 SHA-256 摘要防传输嗅探，并严格 HTTPS + 后端 bcrypt 处理。

前端不该用 bcrypt 做密码加密。这不是“怎么做”的问题，而是“不该做”的原则性问题——所有在浏览器里执行的密码哈希，都绕不开明文密码短暂暴露、盐值无法安全保管、攻击者可任意调试篡改等根本缺陷。

为什么不能在前端

用 bcrypt

bcrypt 的设计前提就是服务端可控环境：稳定 CPU 资源、隔离的执行上下文、可安全生成并保管 salt。而前端：

• 用户输入的密码在调用 bcrypt.hash() 前已是 JavaScript 字符串，可被 console.log、调试器、内存快照直接读取
• 前端无法安全生成或隐藏 salt——任何硬编码或客户端生成的 salt 都等于没加
• 攻击者可轻松替换你引入的 bcrypt.js，返回固定哈希值或直接透传明文
• WebCrypto API 不支持 bcrypt（无原生 SubtleCrypto.digest() 对应算法），所有 JS 实现都是纯计算模拟，性能差且易被逆向

前端该做什么：只做基础防护 + 安全传输

真正该在前端做的，是减少明文在网络中裸奔的时间和范围：

• 用 type="password" 输入框 + autocomplete="new-password" 减少浏览器自动填充风险
• 提交前用 WebCrypto.subtle.digest('SHA-256', ...) 做一次快速摘要（仅防传输层明文嗅探，不是密码哈希）
• 必须走 HTTPS，禁用 HTTP 表单提交
• 配合后端实现 CSRF token 和短时效一次性表单签名，防止重放

const encoder = new TextEncoder();
const data = encoder.encode(document.getElementById('password').value);
const hashBuffer = await crypto.subtle.digest('SHA-256', data);
const hashArray = Array.from(new Uint8Array(hashBuffer));
const hashHex = hashArray.map(b => b.toString(16).padStart(2, '0')).join('');
// 注意：这只是防中间人看到原始密码，后端仍需用 bcrypt/scrypt/PBKDF2 重新哈希

如果非要跑 bcrypt（比如本地 CLI 工具或 Electron）

仅限完全脱离浏览器 DOM 环境的场景，例如 Node.js 后端、Electron 主进程、或 Deno 脚本。此时可用标准库：

• Node.js：推荐 bcrypt（C++ binding，快）或 bcryptjs（纯 JS，慢但跨平台）
• Deno：用官方 https://deno.land/std@0.224.0/crypto/bcrypt.ts
• Electron 渲染进程？不行——它仍是浏览器环境，同上所述风险全部存在

// Node.js 示例（仅服务端/CLI 场景）
import bcrypt from 'bcrypt';
const saltRounds = 12;
const plainPassword = 'user_input';
const hash = await bcrypt.hash(plainPassword, saltRounds);
// 后端存储 hash，登录时用 bcrypt.compare(plain, hash) 验证

真正容易被忽略的点是：很多人把「前端加了一层 hash」误认为增强了安全性，实际上它既不替代服务端哈希，又给攻击者多送了一个可分析的中间态。密码哈希必须发生在可信、隔离、可控的后端环境中，前端唯一职责是安全地把原始密码交过去——不多也不少。