移动端离线AES加密两种CryptoJS实现方案优劣对比咨询

方案1：直接使用用户密码作为加密口令 #

优点 #

• 实现逻辑极简，代码量少，编码出错概率低，调试成本极低
• 无需额外存储辅助参数，本地数据维护成本为0

缺点 #

• 安全性缺陷明显：CryptoJS调用AES.encrypt时如果传入字符串作为第二个参数，内部会默认使用迭代次数仅为1的弱哈希算法派生正式密钥，彩虹表、暴力破解的成本极低，若用户设置的密码强度偏低，密文很容易被破解
• 密钥熵值不足：用户输入的密码大多是常规字符组合，长度有限，远达不到AES算法要求的128/256位密钥的随机熵值，破解门槛极低
• 相同密码加密相同明文会生成完全相同的密文，攻击者可通过密文特征直接推断明文信息

方案2：通过PBKDF2派生密钥后加密 #

优点 #

• 安全性大幅提升：PBKDF2是专门面向密码场景设计的密钥派生算法，10000次的迭代参数会把暴力破解的时间成本拉高到绝大多数攻击者无法接受的程度，即使用户密码强度不高，也能有效提升密文安全性
• 随机盐的加入可以保证即使用户密码完全相同，最终生成的密钥也完全不同，相同明文加密得到的密文也无重复特征，不会泄露明文关联信息
• 参数可灵活调整：可以根据移动端设备性能高低调整迭代次数，在安全性和运行效率之间做平衡，当前10000次的参数在绝大多数移动设备上运行无感知，不会影响使用体验

缺点 #

• 实现复杂度更高：需要将生成的随机盐和密文一起存储（解密时需要用相同的盐才能派生出正确的密钥），多了盐值的读写逻辑，编码失误概率更高
• 密钥派生阶段会消耗少量计算资源，若迭代次数设置过高，低端老旧设备可能出现轻微延迟

场景适配建议 #

你的使用场景是本地离线加密个人信息，优先推荐使用方案2，仅需注意将盐值和密文一同存储即可，盐值本身不需要加密，即使泄露也不会影响密文安全性，额外增加的少量开发成本换更高的安全保障性价比极高。

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