应使用web crypto api的aes-gcm（256位密钥、12字节随机iv）加密敏感数据后再存入localstorage或indexeddb；密钥须通过pbkdf2（≥10万次迭代、随机salt）从用户口令派生，严禁硬编码或明文存储；加密结果需base64编码并结构化存储。
在浏览器中安全加密存储敏感用户数据，核心思路是：不存明文、密钥不硬编码、加密有认证、环境受信任。纯前端无法做到绝对安全，但能有效防止调试查看、意外泄露或中间人截获本地数据。
优先用 Web Crypto API（现代浏览器首选）
这是浏览器原生支持的安全加密接口，算法经过验证，密钥可设为不可导出，比第三方库更可信。
- 用 AES-GCM 加密：它同时提供机密性和完整性校验，避免篡改后解密成功却内容错误
- 每次加密都生成新 IV（12 字节）和 salt（16 字节），不能复用；IV 可与密文一起明文存储，salt 用于密钥派生，也需保存
- 密码派生推荐 PBKDF2：用用户输入的口令 + salt 生成加密密钥，迭代次数设为 100,000 以上
- 密钥对象本身不要转成字符串存 localStorage —— 它应保持为
CryptoKey类型，在内存中使用；若需持久化，导出为 JWK 格式并再次加密后存储
慎用 crypto-js 等纯 JS 库
它适合快速原型或兼容旧浏览器，但存在明显局限：
- 所有逻辑暴露在源码中，攻击者可逆向分析加解密流程
- 默认 AES 模式是 CBC，若未手动配 IV 和 padding，易受填充预言攻击
- 密钥直接写在 JS 里等于“把保险箱钥匙贴在锁上”——必须配合服务端动态下发或用户口令派生
- 如必须用，至少启用 PBKDF2 + AES-256-GCM 组合，并确保 salt、IV、密文分离存储
存储位置与配套防护
加密只是第一步，存哪儿、怎么用同样关键：
- 别用 localStorage 存原始密钥或未加密口令：它是纯文本、无访问控制、易被 XSS 读取
- 加密后的数据可存于 localStorage 或 IndexedDB，但建议搭配 短期时效策略（如 2 小时自动清理）
- 敏感操作前增加二次确认，例如解密支付信息时要求重新输入主密码
- 确保页面运行在 HTTPS 或 localhost 下——Web Crypto API 在非安全上下文中会被禁用
哪些情况不适合前端加密存储
不是所有数据都该在浏览器里加密存着：
- 长期有效的高价值凭证（如 API Token、JWT Refresh Token）——应由后端管理生命周期，前端只持短期 Access Token
- 多设备同步数据（如笔记、文档）——加密密钥难统一，建议服务端加密落盘
- 涉及合规强要求的场景（如金融、医疗）——前端加密不能替代等保/PCI DSS 要求的服务端防护
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
