PHP哈希加密安全吗？MD5 SHA1风险及SHA256推荐

MD5和SHA1已遭实战攻破且被NIST弃用，SHA256虽抗碰撞但过快且无自动加盐与耗时调控；唯一推荐方案是PHP内置的password_hash()与password_verify()，自动加盐、可控耗时、支持算法升级。

MD5 和 SHA1 绝对不能用于密码存储

不是“不太安全”，是已经被实战攻破、NIST 明确弃用的算法。它们的问题不是“可能被破解”，而是：暴力跑一个弱密码（如 123456）在普通笔记本上只要几毫秒；彩虹表能秒查常见密码；更致命的是，md5("admin") 永远等于 21232f297a57a5a743894a0e4a801fc3 —— 攻击者拿到数据库哈希，直接比对就能还原。

• 别信“加个 salt 就行”：手动加盐容易出错（比如盐写死、长度不够、没随机），且无法防御 GPU 加速暴力破解
• 别用“双重 MD5”或“MD5(SHA1($pwd))”：只是心理安慰，计算量没本质增加，反而可能引入弱比较漏洞（比如 0e 开头导致弱等号绕过）
• SHA1 同理，2017 年 Google 已公开碰撞实例（SHAttered），实际攻击成本远低于理论值

SHA256 也不适合存密码，哪怕你用 hash("sha256", $pwd)

它确实比 MD5/SHA1 抗碰撞，但设计目标是「快」—— 文件校验、数字签名才需要快；密码存储恰恰要「慢」。现代显卡每秒可计算上亿次 SHA256，一个 8 位大小写字母+数字的密码，暴力穷举平均只要几分钟。

• hash("sha256", $pwd) 不自动加盐，你得自己生成、存储、管理盐值，极易遗漏或写错
• 没有计算成本调节机制（比如 cost 参数），硬件升级后，破解速度线性提升，你却没法平滑加固
• PHP 官方文档明确标注：hash() 是通用哈希函数，不适用于密码哈希

唯一推荐方案：password_hash() + password_verify()

这是 PHP 5.5+ 内置、官方背书、经过长期安全审计的密码哈希方案。它默认用 bcrypt（PASSWORD_BCRYPT），未来可通过 PASSWORD_DEFAULT 自动升级到 Argon2 等更强算法。

• 自动加盐：每次调用生成全新随机盐，无需你操心存储或格式
• 可控耗时：通过 cost 参数（默认 10，建议设为 12）让单次哈希耗时稳定在 ~100ms，极大拖慢暴力尝试
• 验证极简：password_verify($input, $hashed) 一行搞定，自动提取盐和参数，避免手写比对逻辑出错
• 兼容性好：生成的哈希字符串含算法标识（如 $2y$12$...），旧数据可长期保留，新注册用户自动用更高 cost

示例：

/* 注册时 */
$hashed = password_hash($_POST['password'], PASSWORD_BCRYPT, ['cost' => 12]);
/ 登录时 /
if (password_verify($_POST['password'], $stored_hash)) {
// 验证通过
}

别踩这些坑：从生产环境真实故障反推

很多团队不是不知道 password_hash()，而是在迁移或维护中翻车：

• 把 password_hash() 结果截断存储：MySQL 字段太短（如 VARCHAR(60)），bcrypt 哈希最长可达 60 字符，但 future 算法（如 Argon2）可能更长 → 必须用 VARCHAR(255) 或更大
• 硬编码 cost=10 并遗忘升级：6 年前的 cost=10 在今天已不够，应定期评估（比如每年检查一次，用 password_needs_rehash() 触发平滑升级）
• 在验证前对密码 trim() 或 strtolower()：这会改变原始输入，导致 password_verify() 失败，且破坏大小写敏感策略
• 误用 crypt() 替代：虽然它也支持 bcrypt，但需手动构造盐、处理错误返回、兼容性差，password_hash() 已完全覆盖其能力

最常被忽略的一点：哈希不是加密，不可逆。如果你的业务需要“找回密码”（而非重置），说明架构本身就有安全缺陷——密码本就不该被系统看到。