前端不能安全地做密码哈希，因为浏览器中密码明文极易被恶意脚本、插件或调试工具窃取，哈希结果可能被重放；HTTPS不解决前端执行时的明文暴露问题，且前端无法实现合规盐值与慢哈希。
前端不能安全地做密码哈希——这不是实现问题，而是根本性安全限制。
为什么不能在 HTML/JS 前端哈希密码
用户输入的密码一旦进入浏览器，就已脱离可信环境：任何脚本（包括恶意注入、浏览器插件、调试工具）都能直接读取 input.value 或内存中的原始密码。即使你用 SubtleCrypto.digest() 算出 SHA-256，攻击者仍能截获明文，哈希结果反而可能被当成“等价凭证”重放使用。
- HTTPS 只保护传输，不保护前端执行时的明文暴露
- 前端哈希无法替代服务端盐值（salt）和慢哈希（如
Argon2、bcrypt），容易被彩虹表或暴力破解 - 主流认证协议（如 OAuth 2.1、WebAuthn）明确要求密码必须以明文形式安全送达服务端，由后端完成合规哈希
如果非要前端加一层（仅限特定场景）
仅适用于“降低中间人明文可见性”的弱防护目标（例如内部系统+强 HTTPS+无 XSS 风险），且必须配合服务端二次哈希。不要把它当作安全措施，只算混淆手段。
可用 SubtleCrypto 做一次确定性哈希（注意：不是加密！）：
立即学习“前端免费学习笔记（深入）”；
async function hashPassword(password) {
const encoder = new TextEncoder();
const data = encoder.encode(password);
const hashBuffer = await crypto.subtle.digest('SHA-256', data);
const hashArray = Array.from(new Uint8Array(hashBuffer));
return hashArray.map(b => b.toString(16).padStart(2, '0')).join('');
}
- 必须确保页面未被篡改（CSP 严格策略 + SRI 校验脚本）
- 不能用
MD5或SHA-1—— 浏览器已弃用，且不抗碰撞 - 不能拼接固定字符串当“盐”，因为前端代码完全可见；若需盐，必须由服务端动态下发（但此时已增加往返，失去意义）
- 调用前检查
crypto.subtle是否存在（IE 不支持，旧 Safari 需加webkit前缀）
真正该做的：把密码安全交给后端
前端唯一合规动作是：用 fetch 或 XMLHttpRequest 将明文密码通过 HTTPS POST 到服务端接口，并确保：
- 表单
<input type="password">已禁用自动填充（autocomplete="new-password"） - 提交前校验格式（如长度、字符类型），但不校验“是否为弱密码”（这属于服务端策略）
- 禁用 submit 按钮并显示加载态，防止重复提交导致服务端被撞库
- 响应中不返回任何密码相关提示（如“密码错误” vs “用户名不存在”），避免信息泄露
复杂点在于：很多人混淆了“前端防误操作”和“前端防窃取”。密码哈希这件事，从设计上就不该出现在浏览器里。哪怕你把 argon2-browser 库塞进去跑十分钟，也挡不住开发者工具里一眼看到的原始 password 变量。真要提升安全性，优先审计服务端哈希实现（比如是否用了 Argon2id、迭代次数是否 ≥ 3）、密钥管理、以及登录失败锁定机制。
