You may have already noticed or heard from your clients:
WordPress Multi-Domain Multisite (not subdomain nor subdirectory) has an annoying problem since version 6.8;
Every time you switch from one subsite to another, you have to log in again, and you are logged out of the other subsites.
Let me save you the time and effort:
No, it’s not a Cookie Domain problem, it’s not a Cookie Path problem, and there isn’t some sneaky software logging you out just for fun. It’s a side effect of the new password hash implementation in WordPress 6.8.
In WP 6.8, the hasher was replaced with one based on the PHP functions introduced in PHP 5.5: password_hash, password_needs_rehash, and password_verify. The main actor in our story today is the function password_needs_rehash.
When logging in, WordPress (6/8 an dup) checks “Is the user’s password-hash in the correct format?” If not, WordPress creates a new hash based on the current hashing mechanism. WP will automatically convert old or even insecure hashes (like MD5). This is very handy and absolutely desirable. It’s completely transparent and has been a feature of WordPress since at least version 3.
At this point, you might think: if automatic rehashing has been around for so long, then why is it suddenly causing problems now?
When you’re logged in, you stay logged in (*1). However, WordPress is known for not using classic PHP sessions (*2). So how does WordPress know I’m logged in so I can manage the system?
WordPress does this based on a cookie, which is set during login and validated on every page request. WordPress starts with wp_authenticate_cookie, which in turn uses wp_validate_auth_cookie for a check. Leaving legacy support aside, WordPress looks—among other things—at a fragment of the password, specifically the last 4 characters of the password HASH. And that means: as long as the hash of the password doesn’t change, the cookie remains valid.
And here is the problem: since the hash changes every time you log in, all other sessions are automatically logged out.
Why is this only a problem on a multi-domain Multisite? The answer again is: cookies. Cookies are valid per domain. Subdomains are part of the same domain. For example, a cookie on remonpel.nl will also be valid on example.remonpel.nl, but not on remonpel.net. Subdirectory installations obviously don’t have this problem either: a cookie can be limited to, say, /wp-admin but will still be valid on all directories underneath, such as wp-admin/includes or wp-admin/network. Logging in on the main site will therefore automatically log you in on all subsites in both of these configurations.
(The exception is if your main site is secretly a subdomain; for example www.remonpel.nl. A cookie on www.remonpel.nl will NOT work on example.remonpel.nl.)
Because a cookie is limited to a single domain, when you log in on another domain, you won’t have a logged-in status there, so you must log in again. That changes your password HASH and invalidates the previously set cookie on the earlier domain, meaning you have to log in there again, which changes your HASH… ad infinitum.
What’s the solution?
Simple solutions first: don’t use WordPress 6.8 or newer. Stick your head in the sand… Always works so well… No, of course, this is not a permanent solution, but it can solve your problem in the short term. Unfortunately, this temporary solution means that all users who have logged in with 6.8 already have a new HASH, which is not compatible with 6.7, and so they will need to reset their password—but after that, they can freely navigate across all domains in the multisite.
Solution 2: Use WP 6.8 but with the old hashing mechanism. By defining the global $wp_hasher (in an mu-plugin or earlier in the bootstrap, for example in wp-config.php) using the class found in WP 6.7 (class-phpass.php). Again, users already logged in with 6.8 will need to reset their password. Is this better than solution 1? Well, Yes and no. Yes, in the sense that all WP fixes will continue to apply, but no, because the new password hashing was introduced for security reasons. This is therefore a temporary solution as well.
Solution 3: Use a hook that prevents rehashing from happening. Once in the new hash format, is rehashing still necessary? WordPress thinks so, and in any other situation we’d accept that. However, in a multi-domain Multisite, it’s a hindrance. With the new hashing, WP 6.8 also introduced a new filter: password_needs_rehash. If this returns false, rehashing will not occur. Simply using __return_false here is a bad idea, as it leaves users stuck with old, potentially insecure hashes. But with some logic, this can work. Our solution (for now, because this too is temporary—read on) is to rehash at most once per interval (day, hour, week, whatever you prefer). This way, users can move freely enough between sites, while keeping the system safe. An example implementation can be found at the bottom.
Solution 4: Of course, the best solution is if WordPress prevents unnecessary rehashing. Although not directly, this seems like a bug. Until then, we’ll have to work with a workaround—but choose one that fits: as secure as possible, but without causing unnecessary hassle.
Want to know more? Have something to add? Let me now in the comments.
Example implementation of the password_needs_rehash filter:
*1) As long as no software is installed that actively logs you out after inactivity, or you close your browser tab.
*2) WP does not use PHP session_* functions, so you won’t see a PHPSESSION cookie in a standard installation.
A.I. Notice; This blog post was fully written by ME, not A.I., but I wrote it in Dutch so I asked ChatGPT to translate, after which I changed about 20% of it for readability. So yes; A.I. was used in the production of this post, yet, my thoughts are my own, my solution hand-crafted.
