JavaScript会话变量加解密：密钥暴露风险与实现合理性咨询

核心问题：硬编码密钥等于没加密 #

你当前代码里的PassPhrase = "secret"是硬编码在JS中的，而浏览器端的所有JS代码都是明文可查的——任何人打开开发者工具就能直接看到这个密钥，分分钟解密你存在会话变量里的敏感信息。这种加密方式完全起不到保护作用。

前端存储敏感信息的本质局限 #

前端环境（包括sessionStorage、localStorage、内存变量）本身就不是安全的存储场所：

• 会话变量存在用户本地设备，即使加密，只要密钥在前端，就相当于把锁和钥匙放在同一个抽屉里
• 前端代码无法隐藏任何秘密，混淆、压缩只能增加一点门槛，拦不住真正想获取信息的人

正确的处理思路 #

1. 尽量避免在前端存储敏感信息
   敏感数据（比如密码、用户隐私数据）应该始终留在后端，前端只存储后端颁发的身份令牌（如JWT）。需要使用敏感数据时，前端带着令牌请求后端接口，由后端验证后返回数据。

2. 如果必须在前端存加密数据，密钥不能出现在前端代码里

   • 密钥必须由后端生成，通过HTTPS安全传输给前端，且仅在当前会话内存中使用，不持久化存储
   • 可以让用户提供一个自定义密码（比如登录密码），用这个密码派生密钥，但注意：用户密码不能在前端明文处理，应该先通过HTTPS传给后端验证，再由后端返回派生后的密钥（或用密码加密一个随机密钥后返回）

对当前代码的优化（仅作临时过渡方案） #

如果一定要用CryptoJS，至少要避免硬编码密钥，并且规范加密参数：

// 生成随机密钥（实际场景应由后端生成并传递）
function generateRandomKey() {
    return CryptoJS.lib.WordArray.random(256/8).toString();
}

// 加密函数：显式指定盐、IV、加密模式
function EncryptString(message, key) {
    const salt = CryptoJS.lib.WordArray.random(128/8);
    const iv = CryptoJS.lib.WordArray.random(128/8);
    const encrypted = CryptoJS.AES.encrypt(message, CryptoJS.enc.Hex.parse(key), {
        salt: salt,
        iv: iv,
        padding: CryptoJS.pad.Pkcs7,
        mode: CryptoJS.mode.CBC,
        keySize: 256/32
    });
    // 把盐、IV和密文一起返回，解密时需要用到
    return JSON.stringify({
        ciphertext: encrypted.toString(),
        salt: salt.toString(CryptoJS.enc.Hex),
        iv: iv.toString(CryptoJS.enc.Hex)
    });
}

// 解密函数：对应加密参数
function DecryptString(encryptedData, key) {
    const { ciphertext, salt, iv } = JSON.parse(encryptedData);
    const decrypted = CryptoJS.AES.decrypt(ciphertext, CryptoJS.enc.Hex.parse(key), {
        salt: CryptoJS.enc.Hex.parse(salt),
        iv: CryptoJS.enc.Hex.parse(iv),
        padding: CryptoJS.pad.Pkcs7,
        mode: CryptoJS.mode.CBC,
        keySize: 256/32
    });
    return decrypted.toString(CryptoJS.enc.Utf8);
}

总结 #

前端加密只能作为安全防护的补充，绝不能依赖它保护敏感数据。核心原则是：敏感数据不落地前端，密钥不出现前端代码中。

内容的提问来源于stack exchange，提问作者SkyWalker1963