Inviting a new user to Multisite results in password being emailed

[Ipstenu]

If you add a new user from a site users page (NOT the network one, /sitename/wp-admin/user-new.php ) the flow results in a password being emailed in plaintext.

1) Add new user

2) New user gets email to activate

3) Activate link (ex. example.com/sitename/wp-activate.php?key=5324e8cf2cef143b ) shows the new password

4) The following email is sent:

Howdy anotherstenu,

Your new account is set up.

You can log in with the following information:
Username: anotherstenu
Password: 78HoBi6oFSf9
http://local.multisite-pre.dev/blarg/wp-login.php

Thanks!

--The Team @ Multisite Naked Sites

Whoops.

It looks like this can be fixed for new sites by updating wp-includes/ms-functions.php, however this is set in the database on Network Activation, which means even changing core doesn't update the myriad sites who are merrily emailing out passwords because this is set (wp admin -> Network settings -> Welcome User Email)

Howdy USERNAME,

Your new account is set up.

You can log in with the following information:
Username: USERNAME
Password: PASSWORD
LOGINLINK

Thanks!

--The Team @ SITE_NAME

The attached patch addresses new setups and doesn't break existing ones since I'm really not sure what's best here. I want to say we should edit everyone's DB and change the above block to this:

Howdy USERNAME,

Your new account is set up.

Username: USERNAME

To set your password, visit the following address:

<RESETLINK>

Thanks!

--The Team @ SITE_NAME

However there are myriad people who have customized that simply because they can, and I fear the damage of breaking them.

[Ipstenu]

Change default Multisite NOT to email passwords

[SergeyBiryukov]

Related: #33186

[johnbillion]

Rather than overwriting the entire welcome_user_email option, we could replace the Password: PASSWORD string which is quite likely to appear in the message even if it's been modified.

[SergeyBiryukov]

Replying to johnbillion:

Rather than overwriting the entire welcome_user_email option, we could replace the Password: PASSWORD string which is quite likely to appear in the message even if it's been modified.

How would that work for translations?

[Ipstenu]

I was trying to balance out old and new and make it match what we have in single site. By replacing but leaving the extant search/replace checks, it would not break current Multisite but still get new people 'right'.

Also that way people don't go "This doesn't match what I have in my network admin!"

It's probably a bad idea to search the DB for a perfect match to the old one and replace that, huh?

[johnbillion]

Replying to SergeyBiryukov:

How would that work for translations?

It wouldn't, unless we introduced Password: PASSWORD as a new translatable string as used that for the replacement.

Another option would be to change the behaviour of the PASSWORD token so it outputs the password reset link, but I suspect that's asking for trouble.

[Ipstenu]

Replying to johnbillion:

Another option would be to change the behaviour of the PASSWORD token so it outputs the password reset link, but I suspect that's asking for trouble.

That could wreak havoc with anyone who customized their email. And there's no way to tell who did and didn't. I'm on that knife edge between "For god's sake you're doing it all wrong!" and "I shouldn't break things for people."

[Justin_K]

I was just testing my plugins against WP4.3, and discovered that while I could previously notify only admins of new user registrations by calling wp_new_user_notification() (with no 2nd parameter), in 4.3 the behavior is changed: now it seems to always notify both admins and users (there is no longer a 2nd parameter that can be left blank to suppress emails to users).

How can I get back the behavior of WP prior to 4.3: send new user notifications to the admin *only*?

[johnbillion]

Replying to Justin_K:

How can I get back the behavior of WP prior to 4.3: send new user notifications to the admin *only*?

Sorry you didn't get a more timely response to your comment. This issue has been addressed in #33654, and will be included in 4.3.1.

[thomaswm]

Backwards-compatible fix

[thomaswm]

33209.2.diff​ is an attempt to fix both this ticket and #33186 in a backwards-compatible way. It does the following things:

• Changes the default text for notification emails so that they contain a placeholder RESETPWLINK instead of PASSWORD.
• Performs a simple false !== strpos( $welcome_email, 'PASSWORD' ) check in wp_welcome_notification/wp_welcome_user_notification to see if the email text in the welcome_email/welcome_user_email option contains the placeholder for the password.
  • If it does, then the password is sent to the user in plain text (in order to maintain backwards compatibility).
  • Otherwise, a password reset link is sent instead.

[Mista-Flo]

+1 for this ticket that needs attention.

[eArtboard]

+1

[BjornW]

Updated patch, using apply_deprecated_filters to deprecate password token

[BjornW]

A bit more info about this patch:

In short:

This patch will make a new installation of default WordPress Mu installation safer by removing the plain-text passwords from the welcome_email and welcome_user_email emails. It respects existing installations by not changing their settings (yet), but it will warn them that the PASSWORD token is deprecated.

Details:

• It replaces the PASSWORD token from the default 'Welcome Email' and 'Welcome User Email' template texts with a new token RESETLINK in the code. It does *NOT* change settings in the database to preserve backwards-compatibility.

In a future WordPress version we should remove the PASSWORD token completely and replace it with the RESETLINK token automagically. However doing this now, might be to abrupt for users. Therefor I assume we want to deprecate and warn people first.

• It refactors the PASSWORD token replacement functionality into using a new filter called 'wpmu_replace_password_token'. This filter is being called using ​apply_filters_deprecated to immediately deprecate the function so we can set a notice warning about NOT using the PASSWORD token anymore.

It might even be extended into using an admin notice in the wp-admin for users with super_admin role, to make sure they are aware of this upcoming change

• The RESETLINK token functionality uses a new filter called 'wpmu_replace_resetlink_token' to replace the RESETLINK token for a re(set) url.

To discuss:

1. Is this the proper way to deprecate the usage of the PASSWORD token?
2. Should we warn users with super_admin role about this change using an admin notice?
3. Should we respect the existing settings or replace them automagically with the re(set) functionality now without even warning them?

[BjornW]

mu-plugin which automagically replaces the PASSWORD token for RESET_LINK (and thus replaced with the password re(set) link) including admin_notice for super_admins

[BjornW]

Updated mu-no-plain-password plugin: hides (cannot remove due to lack of filters/hooks in wp-activate) username and password upon activation of user/blog

[Mista-Flo]

Hey, @BjornW Thanks for your work, your patch is pretty solid.

All: Is it possible to move forward and get this ticket handled soon ? We should avoid this lack of consistency between Multisite and non Multisite mode.

Cheers,

[sebastienserre]

agree with @Mista-Flo ! This ticket should be in 5.3

[BjornW]

@Mista-Flo & @sebastienserre Thank you!

I'd like to see my patch added to WordPress, but as you can see there was no response for roughly 7 months...I tried to get a Core committer interested in this by discussing it on Slack, but apparently my timing was not right. It seems WordPress Core is focused on other issues and considers this not a priority now.

Frankly I don't know how to proceed with tickets anymore. It is demoralizing to see (my) contributions lay dormant for so long due to a lack of time/interest from Core committers.

Unless someone with Core commit rights is interested in helping this get into Core, I (as a self-employed developer) find it harder and harder to invest any more time in this (and other WordPress tickets).

Maybe one of you are able to gain the interest of someone with commit rights?

[Mista-Flo]

Well, I have the same experience than you, a lot of tickets take a very long time being reviewed.

But we should thank core committers, they are doing an amazing job, and it's a voluntary one.

[BjornW]

Replying to Mista-Flo:

Well, I have the same experience than you, a lot of tickets take a very long time being reviewed.

But we should thank core committers, they are doing an amazing job, and it's a voluntary one.

Oh, I'm thankful, but also painfully aware that this is a problem which has been going on for quite some time while those able to do something about this ignoring the issue at hand.