1

We have a couple hundred clients (each client is a site) and across them about 15,000 users. We are migrating from Plesk on Centos/Apache PHP 7.0.1 to AWS on Ubuntu/Nginx PHP 7.4.4.

We are migrating using remote sqldumps to a file and then an import into the database on the new server, at command line from new server.

All sites are WP 5.4.

The old database server is MySQL 5.5.61. The new is 10.4.12-MariaDB.

DBs on both servers are collated the same and have the same character sets (utf8mb4_unicode_ci, utf8mb4).

For testing purposes, we are currently migrating some demo sites to a different url (we're not going to port our domain over to the new server until we've got the bugs out of migration and are ready to move). So we migrate them, then update the urls in the db.

Everything works, EXCEPT none of the password hashes work on the new server. The problem isn't that I can't get in (I can do whatever). We want to avoid having 15,000 users have to reset their passwords just because we decided to change servers.

Looking for a way to get this achieved. Is the problem that we are testing by migrating to a different domain? Does the domain somehow play a role in the hashing? Do environment variables play a role in the hashing?

All the salts and stuff are the same because we just copied the files over as is.

By the way each site is on a subdomain of the same domain. So our test migration involves moving Demo from demo.example.com to demo.example2.com.

  • It should be enough to make sure the hashes are the same and all the salts and usernames are the same, are you sure you defined all the salts that need to be defined? Did you literally just copy the files and point it at the original database? Or did you do a proper full migration with a PHP based search replace for the site URL? Have you confirmed the hashes are actually the same? And that the servers have all the necessary PHP extensions ( as the site health screen says? ) – Tom J Nowell Apr 4 at 18:54
  • Confirmed hashes/salts the same. Literally copied the files from one server to the other, including wp-config.php along with everything else. Usernames are all the same. Literally dumped then imported the database. I replaced the urls in wp_options only (for now). Are there other urls somewhere in the db that would affect the hashing? – Works for a Living Apr 4 at 19:26
  • And you're sure all the salts are defined? Not just some of the salts? Migrating a site doesn't change the password hashes, I'm assuming you have no custom login mechanism, or SSO implementation, and that this is a standard WP login page with no additional restrictions? When you say they don't work, can you be specific just so we're clear? Is it the same as typing in the wrong password on a normal install? WSOD? error messages? If your site URL has changed, how did you fix that in the database after import? A direct SQL query? WP CLI? Migration plugin? – Tom J Nowell Apr 5 at 0:36
  • All hashes defined. The hashes haven't changed. That's the firs thing I checked. They are identical in both database. But a log in attempt with the correct username a password fails on the new server while succeeding on the old server. Incorrect username or password error. Changed url using phpmyadmin. – Works for a Living Apr 5 at 6:45
  • Ah, changing the URL via PHPMyAdmin is a huge no no. Lots of URLs are stored in serialized PHP and by using a raw SQL query you've mangled them beyond repair. It may not solve your login problem, but I expect there will be a lot of issues here and there caused by it, and the Admin area might be broken anyway once you get logged in as a result. In the meantime, check these api.wordpress.org/secret-key/1.1/salt to see if there are any missing salts you were unaware of – Tom J Nowell Apr 5 at 11:07
0

No, the site URL and other options are not a factor in password generation in vanilla WP.

In particular, this is the file that does the hash generation:

https://github.com/WordPress/WordPress/blob/master/wp-includes/class-phpass.php

The only way the site URL impacts the password hash, is if you've used the filters to make it that way. Perhaps a plugin does this, but this would be very extremely unusual and rare, and most likely a plugin that claims to improve security.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.