Login to wordpress-site currently not possible: login denied :: `password_hash()` cannot generate a salt.

[thedighubs]

good day dear community,

i have had some issues with the login into wordpress: and yes i am still struggling with these issues ... i have worked on sevreal parts - changed the files and checked the database connection etc. etx

No luck at all - i still stuggle with the login issue - i cannot log into the wordpress-site!
.

my friends they said

if none of these work, try enabling debug mode in wp-config.php (define('WP_DEBUG', true) to identify PHP or plugin errors causing the login failure.

this is very helpful:
argh - i have had a closer look at the debug log
believe it or not - i guess that i have some issues - that might be very big..

PHP Fatal error: Uncaught ValueError: Unable to generate salt

i did alot in the past few days - to find out why the login crashes all the time:

my findings:

WordPress core is fresh. Database is running. Login fails because PHP's `password_hash()` cannot generate a salt.

The PHP build is likely missing the

\crypt`, `bcrypt`, and `openssl` modules, or `password_hash()`

or - they re somewhat broken. so i am at the point to check all my PHP modules that are installed and activce or to recompile the whole PHP-thing."`

More specifically:

\php -m` should list `openssl` and `password`.`
\phpinfo()` shows whether bcrypt is supported.`
Values: \CRYPT_BLOWFISH = 1` → must be present.`

well, i never thought - that the issues were rooted on the server - but i guess that this is the case.
The problem seems to bei that indeed on the server and explains exactly why my WordPress installation crashes during login.

my phpinfo shows (and why WordPress login crashes)

here i have had a quite IMPORTANT FINDING:
The `configure` line contains:

               '--without-curl'

hmm - his means:

 PHP was compiled without \cURL``
]

but wait - afaik WordPress uses `cURL` at several points in the login process – especially for password hashing/salting via `password_hash` when bcrypt or Argon2 is active.
Hmm - i guess that without `cURL` + missing system-wide entropy → PHP sometimes cannot generate a salt

what do you say'!? how do you look at these findings!?

assumption / conclusion: This could be the explanation ( probably a exactly one) what causes the error "Unable to generate salt" – at least the text perfectly matches this setup.

what to do - how to proceed!?

hmmm - what do you think about this issue?!

just want to share these thoughts with you here.


what do you say - what are your thoughts - !?


look forward to hear from you


greetings

 

[RossMAN]

Courtesy of Google Gemini (FREE), I wonder if @Kaido would be proud of me?

----------------------------------------------------------------

This is a classic server-side PHP configuration issue impacting a core WordPress security function.

The user in the thread correctly identified the root cause of the WordPress login failure:

The Problem​

• Error: The login attempt fails with a PHP Fatal error: Uncaught ValueError: Unable to generate salt.
• Root Cause (Confirmed by the user): PHP's password_hash() function, which WordPress uses for hashing user passwords, cannot generate the required secure salt.
• Underlying Server Issue (Highly Probable): The user checked their phpinfo() and found that PHP was compiled with the flag --without-curl. The user suggests that without the cURL extension (and potentially missing system-wide entropy), PHP sometimes fails to generate a secure salt, leading to the error.
  • WordPress relies on secure entropy sources, often accessed through extensions like OpenSSL, cURL, or specific OS functions, to generate strong, unpredictable salts for password hashing (using algorithms like bcrypt or Argon2).

Recommended Solutions and Next Steps​

Since this is a deep server configuration problem, the solution requires access to and modification of the server's PHP environment.

The user's conclusion is likely correct, and the solution is to properly configure or recompile PHP:

Step 1: Confirm PHP Module Status​

Before recompiling, confirm which necessary modules are actually missing or broken.

• Run php -m on the server and check the output for:
  • openssl (Crucial for secure random number generation)
  • password (The module that handles the password_hash() functions)
  • Also, check phpinfo() for CRYPT_BLOWFISH support, which WordPress's default hashing method (bcrypt) relies on. It should have a value of 1.

Step 2: Reconfigure or Recompile PHP (The Main Fix)​

You need to ensure PHP is compiled with the necessary modules to provide a secure source of entropy (a "salt" source) for hashing.

1. Recompile PHP (If Self-Managed Server):
   • If the PHP installation is custom-compiled, the PHP source must be recompiled to include cURL and other necessary security modules.
   • Ensure the --without-curl flag is removed and the relevant flags (e.g., --with-openssl, --with-curl) are included.
2. Use a Different PHP Version (If using a Hosting Panel like cPanel/Plesk):
   • If you are on a managed hosting environment, you likely have a panel (cPanel, Plesk, etc.) that lets you change the PHP version and enable/disable modules.
   • Look for a "Select PHP Version" or "PHP Configuration" tool.
   • Ensure the following extensions are enabled:
     • curl
     • openssl

Step 3: Alternative Fix (If Server Fix is Impossible)​

If you are unable to modify the server's PHP configuration (e.g., on highly restrictive shared hosting), you may be able to force WordPress to use a fallback method, though this is less ideal:

1. Check/Add a Fallback: Ensure your server's Operating System has a functional entropy source like /dev/urandom or /dev/random. password_hash() should typically use these by default if other extensions fail.
2. Temporarily Reset Password (to log in):
   • You can directly reset a user's password in the database (via phpMyAdmin) to a simple MD5 hash. This will allow you to log in.
   • However, WordPress core will immediately try to re-hash the password with a secure method (password_hash()) upon successful login. If the underlying server issue persists, you may be logged out immediately or unable to change any user details. The server configuration must be fixed.

 

[mindless1]

The irony when AI probably caused a problem that needs human intervention to get another AI to fix it.

#getoffmylawn

 

[Kaido]

Courtesy of Google Gemini (FREE), I wonder if @Kaido would be proud of me?

----------------------------------------------------------------

This is a classic server-side PHP configuration issue impacting a core WordPress security function.

The user in the thread correctly identified the root cause of the WordPress login failure:

The Problem​

• Error: The login attempt fails with a PHP Fatal error: Uncaught ValueError: Unable to generate salt.
• Root Cause (Confirmed by the user): PHP's password_hash() function, which WordPress uses for hashing user passwords, cannot generate the required secure salt.
• Underlying Server Issue (Highly Probable): The user checked their phpinfo() and found that PHP was compiled with the flag --without-curl. The user suggests that without the cURL extension(and potentially missing system-wide entropy), PHP sometimes fails to generate a secure salt, leading to the error.
  • WordPress relies on secure entropy sources, often accessed through extensions like OpenSSL, cURL, or specific OS functions, to generate strong, unpredictable salts for password hashing (using algorithms like bcrypt or Argon2).

Recommended Solutions and Next Steps​

Since this is a deep server configuration problem, the solution requires access to and modification of the server's PHP environment.

The user's conclusion is likely correct, and the solution is to properly configure or recompile PHP:

Step 1: Confirm PHP Module Status​

Before recompiling, confirm which necessary modules are actually missing or broken.

• Run php -m on the server and check the output for:
  • openssl (Crucial for secure random number generation)
  • password (The module that handles the password_hash() functions)
  • Also, check phpinfo() for CRYPT_BLOWFISH support, which WordPress's default hashing method (bcrypt) relies on. It should have a value of 1.

Step 2: Reconfigure or Recompile PHP (The Main Fix)​

You need to ensure PHP is compiled with the necessary modules to provide a secure source of entropy (a "salt" source) for hashing.

1. Recompile PHP (If Self-Managed Server):
   • If the PHP installation is custom-compiled, the PHP source must be recompiled to include cURL and other necessary security modules.
   • Ensure the --without-curl flag is removed and the relevant flags (e.g., --with-openssl, --with-curl) are included.
2. Use a Different PHP Version (If using a Hosting Panel like cPanel/Plesk):
   • If you are on a managed hosting environment, you likely have a panel (cPanel, Plesk, etc.) that lets you change the PHP version and enable/disable modules.
   • Look for a "Select PHP Version" or "PHP Configuration" tool.
   • Ensure the following extensions are enabled:
     • curl
     • openssl

Step 3: Alternative Fix (If Server Fix is Impossible)​

If you are unable to modify the server's PHP configuration (e.g., on highly restrictive shared hosting), you may be able to force WordPress to use a fallback method, though this is less ideal:

1. Check/Add a Fallback: Ensure your server's Operating System has a functional entropy source like /dev/urandom or /dev/random. password_hash() should typically use these by default if other extensions fail.
2. Temporarily Reset Password (to log in):
   • You can directly reset a user's password in the database (via phpMyAdmin) to a simple MD5 hash. This will allow you to log in.
   • However, WordPress core will immediately try to re-hash the password with a secure method (password_hash()) upon successful login. If the underlying server issue persists, you may be logged out immediately or unable to change any user details. The server configuration must be fixed.

Bonus tips:

1. Ask it to generate a printable step-by-step PDF checklist

2. Ask it to make you a ZIP with a one-click script to perform the fix

Best practices:

1. "ABC" backup (create a primary, secondary, and spare admin accounts)

How to add a new WordPress administrator user

Read Yoast's help article and get answers on How to add a new WordPress administrator user

yoast.com

2. Add 2FA for admin logins:

WP 2FA – Two-factor authentication for WordPress

Get better WordPress login security; add two-factor authentication (2FA) for all your users with this easy-to-use plugin.

wordpress.org

3. Relocate the default login URL:

WordPress Login URL: How to Find, Change, and Hide It

Learn the essentials of managing your WordPress login page — including how to improve security by changing the URL and how to troubleshoot common issues.

jetpack.com

 

[thedighubs]

Hello and good day dear friends, hello dear Kaido, dear mindless1 and RoseMAN,


first of all: many thanks for the answers - and for the sharing of your ideas and thoughts. Your recommendations are just great. 👍

note: i am on a managed server - which has a backend that is administered by my friend.


This is an update in the story: Unfortunately login still fails, and based on the PHP/WordPress error message (Unable to generate salt) and this ticket from WordPress core: https://core.trac.wordpress.org/ticket/63457

background: …the server appears not to provide a cryptographic entropy source, specifically /dev/urandom.

and yes: Without /dev/urandom, bcrypt cannot generate the salt, so WordPress stores passwords incorrectly as "$wp", and login will always fail.


so i am going to have to check the following on the server:

---

ls -l /dev/urandom
php -r 'var_dump(is_readable("/dev/urandom"));'
php -r 'var_dump(password_hash("test", PASSWORD_BCRYPT));'

If /dev/urandom is missing or unreadable, enabling it will fix WordPress login instantly.


see the newest: update: on november, 7th well i still struggle with the login-it does not work!!!


see here my PHP-Version

• PHP 8.3.27
• Server API: Apache 2.0 Handler
• Loaded Apache modules: mod_php

Kryptografie

• CRYPT_BLOWFISH enabled (für BCRYPT)
• password_hash() unterstützt Argon2
• libsodium aktiv (Standard PHP Sodium Extension)
• but password_hash() does not create a Salt → Exception

important PHP-Konfiguration

• allow_url_fopen = Off
• allow_url_include = Off
• default_charset = UTF-8
• open_basedir = /sites/:/dev/:/tmp/:/tmpfs/
• disable_functions (very many deaktivated – but probalby no ones that affect password_hash() direct)
• session.entropy_file = leer: empty
• session.entropy_length = leer: empty

important Extensions being loaded:

• openssl (but probably Version < 3.4)
• pdo_mysql
• mysqli
• sodium
• zlib
• gd
• json
• hash
• ftp (deaktiviert)
• curl aktiv
• imagick not loaded (relevant for medai but not for Login)

Compiler-Flags (very very important!)

--with-password-argon2
--with-openssl=/usr/local/openssl
OPENSSL_CFLAGS=-I/usr/local/include
OPENSSL_LIBS=-L/usr/local/lib -lssl -lcrypto
ARGON2_LIBS=-L/usr/local/lib/x86_64-linux-gnu/ -largon2


That means: i have no Standard-Paket PHP → but a manually manually compiled one with OpenSSL-libraries.


Assumption: most of the systems run only well if they were compiled with the packet manager - and not manually

conclusion: not wordpress is broken nor breaks all the things – the PHP-compiling is not compatibel with the OpenSSL- and Argon2-libraries.

Additional technical details from phpinfo():

PHP Version: 8.3.27 (Apache handler)
CSPRNG sources:
  /dev/urandom → is_readable() returns TRUE

password_hash():
  → still throws: “Unable to generate salt”
  → WordPress stores "$wp" in user_pass

Loaded crypto modules:```

• openssl (compiled with custom path: --with-openssl=/usr/local/openssl)
• sodium
• CRYPT_BLOWFISH enabled
• BCRYPT supported

PHP was compiled with:

--with-password-argon2--with-openssl=/usr/local/opensslOPENSSL_CFLAGS=-I/usr/local/includeOPENSSL_LIBS=-L/usr/local/lib -lssl -lcryptoARGON2_LIBS=-L/usr/local/lib/x86_64-linux-gnu/ -largon2

Possible issue:
• PHP 8.3.x requires matching OpenSSL + Argon2 + libsodium versions
• PHP is built using custom OpenSSL paths instead of system defaults
• password_hash() fails even though /dev/urandom is accessible

We are searching for:

known good compile configuration for PHP 8.2 or 8.3correct OpenSSL version requirement required flags for Argon2 and libsodium or known bug affecting custom compiled PHP+openssl


I look forward to your ideas and help greetings🤩