PHP password_hash 怎样选择 cost 参数

我第一次把 PHP 登录模块接进低配测试机时，最容易犯的错是把 cost 当成越大越安全的开关。它确实会提高 bcrypt 的计算成本，但登录请求也会更慢，突发登录还会消耗更多 CPU。更稳妥的做法是：先在接近生产的机器上测出交互式登录能接受的耗时，再固定策略，并让旧哈希在用户成功登录时渐进升级。

如果使用 bcrypt，可以先从 PHP 当前默认值附近开始测试；官方手册说明 PHP 8.4 将 bcrypt 默认 cost 从 10 提升到 12，并建议在实际机器上调节，使交互式登录的计算时间低于约 350 毫秒。不要复制别人的 cost 数字，也不要手动保存 salt。

我先把 cost 放进一个很小的登录模块

为了不把讨论停在参数表上，我先假设有一个只有“注册、登录、升级哈希”三个动作的小项目。注册时调用 password_hash()，数据库只保存返回的完整字符串；登录时调用 password_verify()，不要自己拆 salt、算法或 cost。

哈希结果本身带着验证所需的信息，所以数据库字段不要按某一次算法的固定长度设计。我通常直接给密码哈希列留到 255 个字符，并把“哈希生成失败”当成异常处理，而不是把空字符串写进用户记录。

cost 不是拍脑袋：先测一个可接受的范围

PASSWORD_BCRYPT 的 cost 是工作因子，数值提高会增加计算量。项目启动时可以测一组相邻值，例如 10、11、12、13，记录单次哈希的中位耗时和并发登录时的 CPU 余量。测量要使用和线上接近的 PHP、CPU、容器限制与进程模型；在笔记本上的结果只能用来排序，不能直接当生产结论。

 $cost]);
    $elapsedMs = (hrtime(true) - $start) / 1_000_000;

    // 失败时立即中止，避免把无效结果当成性能数据。
    if ($hash === false) {
        throw new RuntimeException('password_hash failed');
    }
    printf("cost=%d elapsed_ms=%.2f%n", $cost, $elapsedMs);
}
?>

我的取舍是先选满足体验目标的最高值，再用压测观察并发登录是否挤占接口预算。不要只跑一次就定案；如果应用有异步注册、批量导入或找回密码任务，还要分别给后台任务设置预算。对于长期维护的系统，优先使用 PASSWORD_DEFAULT，把明确 cost 当成需要复查的策略，而不是永久不变的常量。

核心代码：生成、验证，再决定是否升级

下面的类故意保持很小：生成函数只负责产生哈希，验证函数只负责比较，升级函数只在验证成功后调用。这样既不会把明文密码写入日志，也不会在密码错误时误触发重新哈希。

bcryptCost bcryptCost > 31) {
            throw new InvalidArgumentException('bcrypt cost out of range');
        }
    }

    public function hash(string $plain): string
    {
        // 不提供 salt，让 PHP 为每次密码生成随机 salt。
        $hash = password_hash($plain, PASSWORD_BCRYPT, ['cost' => $this->bcryptCost]);
        if ($hash === false) {
            throw new RuntimeException('password hash failed');
        }
        return $hash;
    }

    public function verifyAndMaybeRehash(string $plain, string $stored): array
    {
        // 先验证正确性，只有成功后才允许升级旧哈希。
        if (!password_verify($plain, $stored)) {
            return ['valid' => false, 'replacement' => null];
        }

        $replacement = null;
        if (password_needs_rehash($stored, PASSWORD_BCRYPT, ['cost' => $this->bcryptCost])) {
            // replacement 由调用方在同一事务中写回用户记录。
            $replacement = $this->hash($plain);
        }
        return ['valid' => true, 'replacement' => $replacement];
    }
}
?>

这里的重点不是把 cost 写成 12，而是把它放在可配置的策略对象里。以后调整参数时，登录代码仍然只处理“密码是否正确”和“是否需要替换哈希”两个结果。

接入登录时，哈希升级要和账户更新绑在一起

登录流程拿到 replacement 后，应在同一个账户更新边界里写回新哈希。密码正确但新哈希保存失败时，不要把这次登录当成升级成功；密码错误时也不要重新计算并覆盖原值。下面的伪代码展示调用关系，实际项目还要接自己的事务和用户模型。

verifyAndMaybeRehash($plainPassword, $user['password_hash']);
if (!$result['valid']) {
    throw new RuntimeException('invalid credentials');
}

if ($result['replacement'] !== null) {
    // 用事务更新同一个用户，失败就回滚，不留下半升级状态。
    $users->replacePasswordHash($user['id'], $result['replacement']);
}

// 到这里才建立登录会话；示例输出表示预期分支，不是本文运行结果。
echo 'login accepted';
?>

我的验收清单：把安全参数变成工程约束

• cost 测试使用接近生产的机器，并记录单次中位耗时、并发 CPU 和超时预算。
• 数据库字段至少能容纳未来 PASSWORD_DEFAULT 变化，当前建议按 255 字符预留。
• 注册和改密只保存 password_hash() 返回值，不保存明文、手工 salt 或独立 cost 字段。
• 登录先 password_verify()，成功后才检查 password_needs_rehash() 并更新。
• 升级写回失败可重试，旧哈希仍能完成本次验证；日志只记录失败类型，不记录密码和完整哈希。

对我来说，合适的 cost 是“在当前硬件和登录峰值下仍能接受的最高计算成本”。它不是一个脱离业务的安全分数。把测量、字段长度、渐进升级和回滚一起交付，才比单独把数字从 10 改成 12 更可靠。

常见问题

cost 越大是不是一定更安全？

计算成本更高会增加离线猜测的单次代价，但也会增加服务端登录耗时和 CPU 压力。应在目标硬件上测量后选择，而不是盲目调大。

为什么不自己保存 salt 和 cost？

password_hash() 已把算法、cost 和 salt 编入返回值，password_verify() 可以直接使用。额外保存一份容易产生不一致，也增加了错误配置机会。

改了 cost 后，旧用户必须立刻重置密码吗？

通常不必。用户用旧密码成功登录后，调用 password_needs_rehash() 判断并生成新哈希，就能渐进升级；长期不登录的账户再按业务策略处理。