网站敏感数据加密存储方案对比：AES、国密SM4与哈希怎么选

用户注册时填了手机号和身份证号，这些信息存到数据库里是明文还是密文？如果你回答的是明文，那一旦数据库被拖库，所有用户信息直接裸奔。

敏感数据加密存储是网站安全防护的基本功，但加密方案不是随便选一个算法就行。不同的数据类型、不同的业务场景，选型逻辑完全不同。

一、需要还原的数据：用对称加密

手机号、邮箱、真实姓名这类数据，业务中需要读取明文使用——比如发短信验证码、发营销邮件。这类数据必须用可逆的加密方式，推荐AES-256-GCM。

AES的优势在于性能好，各大编程语言都有成熟库支持。GCM模式自带完整性校验，比CBC模式更安全，能防止密文被篡改。

密钥管理是重中之重。加密密钥不能写死在代码里，更不能放在配置文件和代码仓库一起。推荐用云厂商的KMS服务，或者自建密钥管理服务，密钥和密文物理隔离存储。业务系统启动时从KMS获取密钥，内存中使用，不落盘。

有个工程细节容易踩坑：加密后的密文长度会比明文长，设计表结构时字段长度要预留。比如手机号明文11位，AES加密后Base64编码大约32位，字段至少给到64位。

二、不需要还原的数据：用哈希

密码是最典型的不可逆数据。用户忘记密码时系统是重置而不是告诉他原密码，所以密码存储只需要单向哈希。

不要用MD5和SHA-1，它们已经被证明不安全。推荐用bcrypt或Argon2id，这两种算法自带盐值，而且可以调整计算成本，抵抗暴力破解。bcrypt的cost参数建议设到12以上。

银行卡号末四位可以单独存明文，用于前端展示。完整卡号加密存储，验证时解密比对。

三、政企项目：优先国密SM4

如果项目面向政府、国企或金融行业，大概率会有国密合规要求。这种场景下对称加密要用SM4替代AES，哈希用SM3替代SHA-256。

SM4算法的128位密钥长度和AES-128对等，性能差距在可接受范围内。各大语言也都有国密库，Java用Hutool的SmUtil，Python用gmssl，PHP用php-sm扩展。

国密改造时注意一个坑：SM4的ECB和CBC模式都不带完整性校验，需要额外加HMAC-SM3来做完整性保护。或者直接用SM4-GCM模式，但部分老版本库可能不支持。

最后强调一点：加密存储只是纵深防御的一环。如果应用层有SQL注入漏洞，攻击者可以通过应用直接调用解密接口拿到明文，加密形同虚设。访问控制、注入防护、日志审计，一个都不能少。