PHP密码哈希验证原理：为什么随机盐值不影响匹配？

在 PHP 密码安全实践中，有一个概念经常让开发者感到困惑：为什么 password_hash() 每次调用都会生成一个完全随机的盐值，但两次对同一个密码进行哈希，结果却完全不同？

var_dump(password_hash("123456", PASSWORD_DEFAULT));
// 输出: "$2y$10$abc123...Kx9ZvQO7JfLmNpRtS"
var_dump(password_hash("123456", PASSWORD_DEFAULT));
// 输出: "$2y$10$xyz789...Wu4VbEgHjIqKlMnOpQrSt"

表面上看，password_hash("123456", ...) 不等于 password_hash("123456", ...)。这正是加盐机制的设计目标：杜绝彩虹表攻击，确保相同密码产生不同哈希。但验证逻辑并不依赖于“解密”或“逆向”，而是“重演”。

✅ 核心原理：哈希字符串是自描述的

你可能会想，既然盐值是随机的，那验证时怎么知道用的是哪个盐？答案其实很简单：password_hash() 生成的哈希值并非一个纯二进制摘要，而是一个结构化、可解析的字符串，里面包含了验证所需的全部元数据。

当调用 password_verify($input, $storedHash) 时，PHP 内部执行以下步骤：

1. 自动解析 $storedHash 字符串，提取算法（$2y$）、cost（10）和 salt（nbX83VUlyVstPCcka vcJy.）；
2. 原样复现哈希过程：用 $input + 提取出的 salt，按相同算法与 cost 重新计算一次 bcrypt；
3. 恒定时间比对（timing-safe comparison）新旧哈希值——若完全一致，返回 true。

所以，盐值无需单独存储、无需传参、更不会丢失——它已经“封印”在哈希字符串中，随密码一同持久化到数据库即可。

? 常见误区与最佳实践

• 不要手动拼接盐：比如 $hash = md5($password . $salt) —— 这属于弱哈希，易受长度扩展攻击，且没有成本因子防护；
• 不要显式传入 salt 参数：PHP 8.0+ 已经废弃了 ['salt' => $s] 选项，强制使用内置随机盐；
• 字段长度务必 ≥ 255：未来如果升级到 Argon2（如 $argon2id$v=19$m=65536,t=4,p=1$...），哈希长度可能达到 200+ 字符；
• 登录成功后检查是否需重哈希：

if (password_verify($inputPass, $dbHash)) {
    // 验证通过
    if (password_needs_rehash($dbHash, PASSWORD_DEFAULT, ['cost' => 12])) {
        $newHash = password_hash($inputPass, PASSWORD_DEFAULT, ['cost' => 12]);
        // 更新数据库中的 password 字段
    }
}

这个机制支持平滑迁移到更强算法或更高 cost，从而提升长期安全性。

? 总结

PHP 的 password_hash / password_verify 组合，本质上是“一次写入、永久可验”的安全抽象。盐值不是额外负担，而是哈希的有机组成部分；验证不是“解密”，而是“精准复刻”。开发者只需要信任这套经过严格审计的原生方案，即可抵御暴力破解、彩虹表、时序攻击等主流威胁——安全，本应如此简单而可靠。