WordPress 密码哈希算法已经从 phpass 改成了 bcrypt
WordPress 在 6.8 版本的时候,将数据库中用户密码的哈希存储算法从 phpass 改为 bcrypt,采用 bcrypt 可大幅提高破解密码哈希的计算成本,从而增强 WordPress 的密码安全性。

此外,应用密码(application passwords)、用户密码重置密钥、个人数据请求密钥和恢复模式密钥也将从 phpass 改为 BLAKE2b,这是一种通过 Sodium
实现的加密安全但速度较快的哈希算法。
目前仅剩文章密码(post passwords) 还在使用 phpass
,未来可能在做进一步的如何优化文章密码的哈希和验证机制的研究之后再进行调整。
自动调整
这个调整是自动且静默的,就是说不会影响现有密码或密钥,站点管理员或用户也无需采取任何动作,升级到 6.8 后,用户无需去更改或重置用户密码,之前版本 WordPress 存储的密码和密钥会继续有效,已登录用户的会话仍会保持有效。
当用户首次登录,或在更改密码时,其密码会自动使用 bcrypt
重新哈希并保存到数据库,应用密码和安全密钥不会自动重新哈希,之前生成且在过期前使用则仍会保持有效。
phpass 生成的哈希可以在不同站点、环境和服务器之间移植,改用 bcrypt 和 BLAKE2b 后,这一特性仍然保持不变,因此迁移到其他服务器,或升级 PHP 和 WordPress,密码仍会正常运作。
对于普通用户来说。看到这里就差不多,你需要了解到的就是 WordPress 的用户密码哈希算法换成更安全的 bcrypt,然后应用密码和其他密钥则换成 BLAKE2b,然后无需做什么,WordPress 会自动调整。
下面是程序员了解的。😁
密码函数得到了更新
wp_hash_password()
和 wp_check_password()
函数已经更新成改用 PHP 原生的 password_hash()
和 password_verify()
函数,并使用 bcrypt 算法和 SHA-384 预哈希,wp_check_password()
函数依旧对 phpass 哈希的密码的支持,这样也就保持现有的密码不会失效。
此外,这两个函数仍继续支持通过 $wp_hasher
这个全局变量来实现替代原有的哈希机制。
WordPress 新增了一个新的 wp_password_needs_rehash()
函数,作为 PHP 原生函数的 password_needs_rehash()
的封装,如果想要调整其的逻辑,还可以使用 password_needs_rehash
filter,并且该插件可替换的,如有需要可以自定义一个覆盖它。
SHA-384 预哈希的作用是为了避免 bcrypt 对密码长度(72 字节)的限制,密码哈希之后会加上 $wp
前缀,以区别于 bcrypt 默认生成的哈希,所以这样默认完整的前缀为 $wp$2y$
。
新增了两个快速哈希函数
以下两个函数通过 Sodium 实现了加密安全但速度较快 BLAKE2b 算法:
wp_fast_hash()
:用于随机生成的高熵字符串进行哈希处理(建议至少 128 位,适用于无过期机制的密钥)。
wp_verify_fast_hash()
:用于 wp_fast_hash()
生成的哈希值,并支持回退到 phpass 哈希
开发人员需要做什么?
使用 wp_hash_password()
和 wp_check_password()
函数的代码将继续工作,无需做任何修改,但是直接使用 phpass
哈希的代码那就要做一些修改了。
这也是我强调如果 WordPress 有对某个功能做了一层包装的函数,那就要该函数的原因,WordPress 底层替换之后,对应的处理也会进行处理,直接使用 WordPress 函数就无需做人修改了。
那么具体哪些情况需要修改呢?
- 验证用户密码哈希的代码应改用:
wp_check_password()
。 - 验证应用程序密码、密码重置密钥、个人数据请求密钥或恢复模式密钥的代码应改用:
wp_verify_fast_hash()
。 - 如果使用了自定义
wp_hash_password()
或wp_check_password()
函数的插件,除非这些函数实现了其他哈希算法,否则可移除以让 6.8 新增的 bcrypt 哈希算法实现生效。
其他认证机制(如 SSO、社交登录、一次性登录) 通常不受影响,但仍建议检查是否涉及密码哈希或密钥处理。多因素认证(MFA/2FA) 也不太可能受影响。