WordPress 6.8 will fail creating bcrypt when entropy sources are not available

[isgroup]

Regarding to: ​https://make.wordpress.org/core/2025/02/17/wordpress-6-8-will-use-bcrypt-for-password-hashing/

If /dev/urandom is not available (for example) the database field will be set to "$wp", making impossible for users to login.

This may happen in chroots or other container/vm/jail systems.

The error generates is:

[Sat May 17 XXX 2025] [proxy_fcgi:error] [pid XXX] [client XXX] AH01071: Got error 'PHP message: PHP Warning: password_hash(): Unable to generate salt in /wp-includes/pluggable.php on line 2709'

But the application does not fail and simply puts "$wp" in the "user_pass" column.

This happens every time wp_hash_password() is used (user creation, change password, etc).

[johnbillion]

Thanks for the report @isgroup. This sounds like a pretty serious problem with the hosting environment because all manner of CSPRNGs and related cryptographic functionality relies on /dev/urandom.

• What is the use case for running a system where /dev/urandom is not available? What is the source of randomness in this case?
• Which version of PHP are you using? The PHP documentation implies that this error should throw an exception when using PHP 8, but it's not entirely clear.

[isgroup]

Hi @johnbillion@, thanks for your reply. It's an edge case but MAY happen.

• What is the use case for running a system where /dev/urandom is not available? What is the source of randomness in this case?

Chrooted PHP-FPM with no access to /dev/ for example, but could occur also when the entropy pool is exhausted. So it would be better to check if password_hash() or underlying functions emit warnings or errors in order to have a more deterministic behavior.

Another method would be to check if the generated hash has the correct format (eg. check for length).

• Which version of PHP are you using?

From my understanding this could happen interdependently from PHP version, 7.4 onward.

To reproduce simply create a docker and chmod /dev/urandom so that PHP can't access it. Old password methods will work (eg.: $P$) but the newer method will emit a warning a put ONLY "$wp" in the field.

Regardless, my observations are that login fails, so I can't say it's an authentication bypass, but maybe more experienced WP developers have a different take on this matter. That's why I marked the ticket as User and not Security.