WordPress.org

Make WordPress Core

Opened 19 months ago

Closed 19 months ago

Last modified 17 months ago

#42967 closed feature request (invalid)

New admin email change featuer should be rolled back

Reported by: johndeebdd Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.9
Component: Security Keywords: close
Focuses: Cc:

Description

Suggest rollback of core ticket #39118.

A new feature was added to single site core. It involves the method by witch an admin can change the admin email for the site. Previously, a user could log in as an admin and change the email, just like every other setting. The new feature has the system send a confirmation email to the new email before the change takes place. There are two major problems with this new approach:

In many cases, a person might install WordPress without having previously setup an admin email. This could be for development purposes, or because their admin email is somehow inaccessible. With the new change, the system must have access to the OLD email, from which the confirmation email is being SENT. What is the reason an admin might want to change their email? One of the mail reasons seems to be that the old email is not accessible to them. Presumably if the email is unaccessible to the user, it would be also unaccessible to the WordPress install trying to send the confirmation email! With the new system, you cannot change the admin email if the system cannot SEND emails. This is a terrible idea, because in my experience setting up the ability to send emails is one of the touchiest things in WordPress, often the last thing done. Many admins use Gmail because setting up a domain specific email server is a daunting task.

Normally, the canonical method that the server uses to identify the penultimate credential, is the password the admin enters when they install WordPress. Note that you can install WordPress with an email that is NOT accessible, as in "dummyemail@…". This new technique makes the penultimate password external to WordPress [but weirdly just for this ONE setting]. For instance, if Gmail were to simply go out of business, it would become impossible - within WordPress - for that admin to change his own password or register a new admin. Also, this setting now becomes hostage to network activity. It is possible sent emails are being blocked or held up downstream, in which case this setting would become unchangeable via WordPress directly.

I understand that the perception is that this provides an extra layer of security, but it really just provides an extra layer of complexity. If a user is logged in as an admin, he should be able to change all the settings on the site without having to provide MORE credentials to some other third party.

Note this would be the only setting in the entire system that works this way. You can change every other setting with only admin credentials, not admin + email server credentials. Also, I CAN change the admin password, I just have to understand PHP [since an admin can run arbitrary code]. A security feature that only protects against people with extremely limited skills isn't a feature. So this doesn't actually add security, it just ads the PERCEPTION of security, which is bad.

ISSUE #2: This is the only instance where a single site addresses the admin with the pronoun "we". When I saw this, my jaw dropped. Who is the "we" that is going to email me? Is someone else gathering emails from my privately hosted site? The pronoun "we" should not be used here.

Suggestion: This entire feature should just be rolled back. It's not an improvement.

Attachments (2)

emailnew.png (179.7 KB) - added by johndeebdd 19 months ago.
screen shot
emailold.png (154.7 KB) - added by johndeebdd 19 months ago.

Download all attachments as: .zip

Change History (15)

@johndeebdd
19 months ago

screen shot

@johndeebdd
19 months ago

#1 @fierevere
19 months ago

You still can directly edit things in mysql tables, in case of real emergency.

#2 in reply to: ↑ description @Clorith
19 months ago

Hi there, and welcome to Trac!

I'd like to address your concerns here, as I think some of them may be a misunderstanding of how WordPress handles the email process.

Note that I'll skip many sections, because the answers to many of them are all covered in the first response.

The most notable point you make is that WordPress needs access to your emails to do anything, which is incorrect.

WordPress doesn't access your email to send anything, it is sent by the server your website is hosted on, and the sender will be automatically set as wordpress@<your-domain.tld>, unless a plugin is set to modify this.

You don't need to set up anything for emails to be sent inside WordPress it self. For some users, they will have set up a plugin that passes emails through an external SMTP server, this is then a deliberate choice and the user setting this up should be able to change the settings within that plugins interface if it should no longer be correct.

You are right that if your site can't send emails, it becomes problematic to do these changes, but if that's the case one should contact their host as it would also prevent other legitimate functionality such as password recoveries.

This is the only instance where a single site addresses the admin with the pronoun "we". When I saw this, my jaw dropped. Who is the "we" that is going to email me? Is someone else gathering emails from my privately hosted site? The pronoun "we" should not be used here.

This part can understandably be confusing in some scenarios, I would suggest creating a separate ticket to look at finding better wording for this.

#3 @johndeebdd
19 months ago

Thank you Clorith. I don't think I'm making myself clear. This is an issue for sysadmins, not shared hosting customers. I'll summarize:

This is a NEW feature, nothing to do with how emails work. The new feature is that as of 4.9, when you change the admin email in a single site, you must confirm the email before the change takes place, like when a new user registers. But this new action restriction is placed on a LOGGED IN ADMIN.

The stated purpose of this new feature, as per the announcement, is "The intention is to make it more difficult for an attacker to take over a user account or a site by changing the email address associated with the user or the site, and also to reduce the chance of a mistaken or erroneous change causing you to get locked out."

The author of this feature thought he was confirming if the recipient email is valid. That's only half true. It's also inadvertently testing if the server can SEND emails. I don't think that was considered. In other words, for the admin to do this action, he has to be logged in via the normal WordPress auth cookie AND the server has to successfully connect to outgoing SMTP. This is the absolute only setting in WordPress that requires the system to also have credentials to an outside service not listed in the wp-config.php file. SMTP is, by definition, an outside service, and admin actions shouldn't be restricted in a new way like this. Additionally, it doens't actually provide the protection it thinks it does, since a logged in admin can run arbitrary code and alter the site email anyway.

Also note that many applications use WordPress without having access to outgoing mail. Now they cannot change the admin email of the site.

It seems the initial desire was to improve security. It doesn't do that, but it DOES create new restrictions on how WordPress can be installed and used. Previously, an admin could change the site's email. Now the admin must have outgoing SMTP access to do this, and that access is controlled outside of WordPress, but WordPress still relies on it. All the while still allowing this logged in user to run arbitrary code and defeat the new restriction in any case.

#4 follow-up: @knutsp
19 months ago

Why would anyone bother change the email address if the server can't send emails? In such case any stored email address, for the site or for users, are completely unusable.

A confirmation is sent to the new address, as a kind of sanitation of the email address. The old address is not involved in this process. If the confirmation cannot be received by the admin there is no point in committing the change.

A lot of applications use some extra, or repeated, credentials to change certain settings. All changes of all email addresses in any system should be confirmed by proving you can receive a message by it.

#5 follow-up: @mark-k
19 months ago

@knutsp even if emails can be sent, the admin might have created a user for a "guest" author without knowing the email, or have done a mistake while entering it. Now the user can not change it, which is not optimal.
At least in that case he can contact the admin, but what happens if some previous admin have create a new admin acount and went for a 3 months sabatical? How will the new admin correct his faulty email address?

It is not great from security POV, but admin users should probably be able to change their own email address without verification. (as said above, they probably can do the change directly in the DB, but why to force people to do such things?)

#6 @Clorith
19 months ago

  • Keywords close added

@mark-k You do not need access to the old email address to change anything, you need access to the new address, which is where the confirmation email is sent from WordPress.

Here's the current flow:

  • User is registered with the email address username@hotmail.com
  • User goes into their profile page in the WordPress admin
  • User edits the email field and changes it to username@gmail.com
  • WordPress sends an email to username@gmail.com with a link to click to confirm the address change
  • User clicks the link in the email to change their address
  • WordPress sends an email to username@hotmail.com with information that the address has now been changed to username@gmail.com

No access to the old address is required, it is merely included in the flow as a courtesy (and security precaution, in case of a malicious change the user is now made aware of that change) to inform of an already completed change.

---

Honestly, for the vast majority of users, this behavior isn't a problem (and for many, probably expected as most services you encounter these days require email verification on edits), as such I would say this is a wontfix issue, as the behavior can be controlled via filters and actions for those unhappy with the implementation, but will leave it open for final input by the implementing deveoper.

The send_email_change_email filter will allow you to prevent sending the email, and also provides you with the data the user supplied, this can be used to override things and store the new email straight away.

#7 in reply to: ↑ 5 @knutsp
19 months ago

Replying to mark-k:

@knutsp even if emails can be sent, the admin might have created a user for a "guest" author
without knowing the email, or have done a mistake while entering it. Now the user can not change > it, which is not optimal.

He can, as long as the new one is correct.

If not, the change will be pending and the user may retry.

With this implemented change the site email gets the same treatment as for users.

#8 in reply to: ↑ 4 @johndeebdd
19 months ago

Replying to knutsp:

Why would anyone bother change the email address if the server can't send emails? In such case any stored email address, for the site or for users, are completely unusable.

Knutsp, there are MANY use cases for using WordPress without having external email capability! Single page web apps, apps behind firewalls, API projects etc. Both SMTP and FTP are sperate services from WordPress, and you should be able to opperate without either. [In fact you CAN opperate without either, except for this ONE SINGLE SETTING, which is the issue].

#9 @johndeebdd
19 months ago

Here's the current flow:

  • User is registered with the email address username@hotmail.com
  • User goes into their profile page in the WordPress admin
  • User edits the email field and changes it to username@gmail.com
  • WordPress sends an email to username@gmail.com with a link to click to confirm the address change
  • User clicks the link in the email to change their address
  • WordPress sends an email to username@hotmail.com with information that the address has now been changed to username@gmail.com

No access to the old address is required, it is merely included in the flow as a courtesy (and security precaution, in case of a malicious change the user is now made aware of that change) to inform of an already completed change.

---

Honestly, for the vast majority of users, this behavior isn't a problem (and for many, probably expected as most services you encounter these days require email verification on edits), as such I would say this is a wontfix issue, as the behavior can be controlled via filters and actions for those unhappy with the implementation, but will leave it open for final input by the implementing deveoper.

The send_email_change_email filter will allow you to prevent sending the email, and also provides you with the data the user supplied, this can be used to override things and store the new email straight away.

You're looking at it from the point of view of a shared hosting user. You're not looking at it from the point of view of a sys admin who has to install WordPress themselves. How can WordPress SEND an email if you don't have access to the OLD email? What if the OLD email was setup as "dummy@…"? You don't need external SMTP to install WordPress, but as of now, you do infact need it to CHANGE the email. So you can install it fine, just not change it [yet you can run arbitrary code]. That's weird - and new, and a unique case in WordPress.

Here is how WordPress is setup:

  • WordPress receives an HTTP request and is activated without wp-config and goes into install mode.
  • DB creds are entered, and the system asks the admin for an email WHICH IS NOT CONFIRMED, JUST ACCEPTED. I think this is the misunderstanding. You DO NOT need to confirm the initial admin email, and this is absolutely by design. i.e. localhost installs, single page apps. There are MANY uses of WordPress besides blogging on a shared host with email setup. I was brought here because this cause a problem in one of my apps.

The CHANGE:
Previously, admins could change the site email without a confirmation. For instance, they STILL can create users without email confirmation. The change is that they cannot change the site email. This is absolutely different from other emails, and doesn't make sense. It was made by someone who doesn't understand that on single sites, there is no "super admin", just "admin" who is the penultimate. The change assumes there is someone besides the "admin" who could control outgoing SMTP, this isn't the case.

Questions:


What is the benefit to create this new restriction?
Do you understand this is a NEW thing, that previously an admin could operate WordPress without restriction, and now this additional restriction has been made?


Do you understand this creates a new class of settings. This is the ONLY setting in WordPress which has this characteristic:

-This setting cannot be changed by the logged in user with capabilities to in fact change it
-This same user [a logged in single site admin] CAN run arbitrary code
-This same user CAN still actually affect to change the setting, they just need to know PHP - this is a SERIOUS security flaw. A co-admin might assume another admin couldn't change the site email, since he can't. But the co-admin would be wrong! This is the only example of this in the system.
-This setting requires external send SMTP to be changed by a logged in admin


Do you understand this is a CHANGE, that previously no setting existed with the characteristic?


Do you understand that if you install WordPress without external SMTP, you can never change the admin email within WordPress [but not really, because you can run arbitrary code]?

#10 @NathanAtmoz
19 months ago

The changes in #39118 are beneficial to the majority of use cases and I don't think they should be reverted.

In the case that you're a sys admin, and you want to changed the site email, and outgoing email is not available, and you're unable to query the database to update the administrator password field, then you can add the following as a must-use plugin:

add_action( 'load-options-general.php', function() {
  $new_admin_details = get_option( 'adminhash' );
  if( is_array( $new_admin_details) && ! empty( $new_admin_details ) ) {
    update_option( 'admin_email', $new_admin_details[ 'newemail' ] );
    delete_option( 'adminhash' );
    delete_option( 'new_admin_email' );
    $redirect = 'options-general.php?updated=true';
    wp_redirect( admin_url( $redirect ) );
  }
});

Then you'll be able to change the email addresses on the Options General page without email confirmation.

#11 @johnbillion
19 months ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

The points made above by knutsp and Clorith are correct.

The old address is unconnected to the process of changing the admin email address. It is literally not used (apart from a courtesy notification to the old address after the confirmation link is clicked).

The confirmation email doesn't get sent from the old address. If it does in your case, then something on your site has been configured to do so, for example a plugin or theme on your site. I suspect your site has an SMTP plugin in place which is configured to send emails from the existing admin email address. If that's the case, then you ought to reconfigure it to send it from an address which is capable of sending emails, otherwise it serves no purpose anyway.

#12 @johnbillion
19 months ago

Unrelated aside: The wordpress-bdd.com domain name violates the WordPress trademark policy. You may want to change it.

#13 @wesleypeace
17 months ago

@johnbillion I'm still a little confused by what I'm seeing. I believe I understand what has been said here regarding the reason for the change; BUT, I'm not sure if I got the real answer for what I see as the problem. ...No confirmation email is being sent to the default admin user when that email address is changed. Why is that happening?

I have the same problem on multiple sites caused by a default install of WP by the host provider.

Yes, I see the above script, but I don't see that as a viable solution for the masses.

Note: See TracTickets for help on using tickets.