PHP password_hash 怎样选择可迁移的密码算法

给登录系统换密码算法时，真正麻烦的不是把 password_hash() 调起来，而是旧哈希已经落库、不同机器的算法能力不一致，未来默认算法还可能变化。我的做法是：新用户优先使用 PASSWORD_DEFAULT，把数据库字段留到至少 255 字节；如果部署环境明确支持 Argon2，再评估 PASSWORD_ARGON2ID；登录成功后用 password_needs_rehash() 渐进升级旧记录。

可迁移的关键是“验证接口稳定、存储空间充足、升级发生在成功登录之后”，而不是把某个算法名永久写死。PASSWORD_DEFAULT 的具体算法可能随 PHP 的完整版本变化，哈希结果本身已经携带验证所需的算法、cost 和 salt 信息。

官方依据：https://www.php.net/manual/en/function.password-hash.php

本文只讨论 PHP 原生密码哈希的选择与迁移，不讨论自研密码算法、明文存储或绕过认证。

先用 PASSWORD_DEFAULT 作为可迁移默认

如果应用没有明确的跨平台约束，我会先把新密码的入口写成 PASSWORD_DEFAULT。PHP 手册说明它当前使用 bcrypt，但这个常量的设计目标就是在未来切换到更强算法，因此代码不需要跟着每次默认算法变化而重写。

这也决定了字段设计：不要按当前 bcrypt 结果的 60 个字符卡死列宽，使用 VARCHAR(255) 或更宽的等价字段。手册特别提醒，PASSWORD_DEFAULT 的结果长度可能随时间改变。

最小配方：先看环境，再决定是否显式用 Argon2id

PASSWORD_ARGON2ID 适合已经确认 PHP 构建具备 Argon2 支持、并且服务端能承担相应内存与计算成本的部署。它不是只改一个常量就结束：生产环境、队列 worker 和测试环境的能力都要纳入同一套部署判断。

如果多个运行环境的 password_algos() 结果不同，不要让同一批应用实例各自选择策略。更稳妥的做法是把算法策略作为部署配置统一下发；无法统一时，就使用所有实例都支持的 PASSWORD_DEFAULT。需要强制跨环境兼容时，显式选择 PASSWORD_BCRYPT 也可以，但要接受它的参数边界和未来迁移成本。

把参数边界写进配方，而不是凭感觉调 cost

bcrypt 会把输入密码截断到最多 72 字节，所以前端允许超长密码时，后端仍要明确告知这一边界，不要误以为超过部分继续提供了等量保护。另一个常见误区是手动生成 salt；PHP 8.0 起显式提供的 salt 会被忽略，官方建议直接使用自动生成的安全 salt。

cost、memory_cost、time_cost 和 threads 都应在实际机器上测量。官方示例把交互式登录的哈希耗时控制在约 350 毫秒以内作为参考目标；PHP 8.4 还把 bcrypt 默认 cost 从 10 提升到了 12，因此不能把旧机器上的耗时假设带到新版本。

 12];
$hash = password_hash($plainPassword, PASSWORD_BCRYPT, $options);

// 登录校验统一使用 password_verify，不要自行拆 hash 字符串比较。
$valid = password_verify($plainPassword, $hash);
echo $valid ? '密码匹配' : '密码不匹配';
?>

如果选择 PASSWORD_DEFAULT，通常不需要手动固定 cost；如果显式选择 bcrypt 或 Argon2，则应把参数当作部署策略管理，并在升级 PHP、迁移机器或调整资源后重新测量。

登录成功后用 password_needs_rehash 迁移

迁移旧算法时，不要拿数据库里的旧哈希直接重算，也不要在密码尚未验证时覆盖它。正确的切入点是：先用 password_verify() 验证用户刚提交的密码，验证成功后再检查当前哈希是否符合新策略，最后用同一个明文密码生成新哈希并更新记录。

这种方式不会要求一次性重置全部用户密码：活跃用户在下次成功登录时升级，长期不登录的旧记录继续由 password_verify() 识别。若策略是显式的 Argon2id 或 bcrypt，password_needs_rehash() 的第二、第三参数就应传入同一套算法和 options。

常见问题

为什么不永远固定 PASSWORD_BCRYPT？

如果确实需要跨环境固定 bcrypt，可以显式指定；但它会把算法选择和 72 字节输入限制固定在当前策略上。没有这种兼容要求时，PASSWORD_DEFAULT 配合足够宽的字段更利于后续升级。

数据库字段为什么建议 255 字节？

因为 PASSWORD_DEFAULT 的结果长度可能随未来默认算法改变。按当前 60 字符结果设计，迁移时可能出现截断；VARCHAR(255) 是手册给出的合适预留方向。

总结

PHP password_hash() 的可迁移方案可以归纳为四点：新代码优先使用 PASSWORD_DEFAULT；字段按未来长度预留；Argon2id 或 bcrypt 的参数要结合实际环境选择；旧哈希只在 password_verify() 成功后通过 password_needs_rehash() 渐进升级。这样变化被封装在验证与迁移策略里，用户不需要因为算法演进而一次性重置密码。