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 一并下发，且单次有效。
OC SSH Tunnel Node Recovery
下载
诊断并恢复通过 SSH 隧道连接的 OpenClaw 节点。用于解决配对必需错误、隧道冲突、远程端点错误以及 SSH 目标配置错误等问题。
立即学习“Java免费学习笔记（深入）”；
后端才是密码安全的核心防线
所有密码必须在服务端用专用密码哈希函数处理：
- 推荐 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 库前端校验）
