Featured

WordPress Plugin: Change Admin Email – running on over 40k servers!

General Chicken publishes a plugin in the wordpress.org repo: Change Admin Email Setting Without Outbound Email

As of WordPress 4.9, the administrator cannot change the site admin email without outgoing email setup on the server, and recipient email credentials. This plugin restores the admin’s ability to change this setting without sending a confirmation email.

Plugin in the wordpress.org repo:

Change Admin Email


Plugin on Github

Resources and Discussions about Forking the WordPress Codebase

https://github.com/johnpbloch/wordpress

What WordPress Can Learn From the Ghost Project

I Will Never Fork WordPress

Gutenberg and the Future of WordPress: Conditions for Success

The Ultimate Overview of the WordPress Block Editor (Gutenberg) for Developers in 2022


https://dev.to/scottybo/classicpress—a-wordpress-fork-without-gutenberg-2e6f
https://dev.to/scottybo/classicpress—a-wordpress-fork-without-gutenberg-2e6f/comments
https://digwp.com/2017/11/thoughts-on-gut
https://john.onolan.org/project-ghost/enberg/
https://packagist.org/packages/jesseberkhof/wordpress-fork

Time to Fork WordPress for Enterprise Power or Blogger Simplicity?

How to fork WordPress away from the WordPress foundation

The WordPress foundation is corrupt.
Now when I say that, I first want to thank them for their fantastic work in the past. However, because of issues of free press, democracy, humanism, and humanity: we need a global, open source, content manangement and publishing platform, that is free, has wide, ubiquituous adoption, and which isn’t controlled by nation state or corporate interests.

Introductin FreePress.

Case study interview

What technologies are you using?

What needs do you think they full fill?

What value do these tech provide?

What is your dev process?

How many people are employed?

What roles do people play in the company?

Do you use outsources?

Plugin domain: server side / client side / mix ?

api?

Networking?

Auth?

What does the plugin do?

Are you using BDD / TDD?

Are you testing post development?

Agile, Srum, mix, face to face, JIRA?

Testing frameworks? Libraries?

Roles in BDD? Same person who writes tests solves them?

Tests written first or after?

Pair programming, Group? mob? cubicle?

WordPress developers should fork to overthrow the Foundation

The WordPress developer community should overthrow the Foundation and create a truly open sourced CMS platform for humanity to use.

The WordPress Foundation is a mere shill for Automatic, and a serious threat to the platform. Multi-site, and now Gutenberg, are both obvious attempts to inject their own corporate interests at the expense of the community.

More to come. If you’d like to read more, make a comment.

Implied role structure on multisite versus single site

In WordPress 4.9 a new feature was added where a confirmation email is sent when an administrator tries to change the site email. In WordPress, the ultimate role is administrator. There is a flag for an

As will be shown, the new feature actually requires three seperate user roles: an installing-admin, a change-initiator-post-install-admin, change-completor-post-install-admin, and these can be different users with different implied capabilities, although this doesn’t seam to have been considered.

Role
installing-admin can set site admin email without confirmation
post-install-admin

cap#1: the capabilitiy to set the site email without confirmation. cap#2: the ability to set it with confirmation. It is my contention this is not clearly understood.
The error comes from the fact that in multisite, there are in fact two roles: super admin, and regular administrator. These roles usually coincide with the different capabilties. Under most work flows using multisite, there is a peer class [usually one induvidual user per site per class, but it could be many users] of users that defines these implied roles. In other words, on multisite, usually there is one super admin, and one regular admin per domain, and the fact that this feature requires two different sets of capabilities wasn’t noticed before because there are in fact two user types in multisite. On single site, there are just “administrators” – one peer class of users with the same [or they SHOULD be the same] capabilities. My contention is that this new feature creates an illogical jumble of the capabilities in single site, and this was not noticed because the bifiracaption wasn’t noticed on multisite [where the feature came from].

A valid use case for confirmation emails

There is a business value to the use case pattern on many internet platforms where a confirmation email is sent, and then an encrypted or nonced link must be clicked to perform the confirmation action. The value of the features is:

The pattern confirms the user receiving the email has credential access to the receiving email account, reducing SPAM, and increasing security.

When you signup for Facebook, they send you an email with a link to confirm your account before it become active. This proves to Facebook that the recipient email is alive, and the http user requesting the account has recipient credentials for the email account.

This seams to be the intended purpose behind the admin email confirmation feature as of 4.9, as well as providing additional security to the system. My contention is that this is a confused purpose, and in fact renders WordPress LESS secure for several reasons.

Similiarity to the add user feature
When a user registers for a WordPress site, a confirmation email is sent to him from the site, to confirm the user has access to the email. This valid use case, is identical to the one used by facebook.com, described above. It is the confirmation of some information between two human groups / persons [the stakeholders of the site, and the user who is trying to register].

It is important to understand: THIS IS NOT A SECURITY FEATURE! An administrator can run arbitrary code. There is a check box available for administrators to override the outbound email:

confirm_user_email_being_sent
confirm_user_email_being_sent

Why can’t this emial be a true security feature?
In computer science, there is a concept called “arbitrary code”. A user who can run arbitrary code can literally do anything on the system, and can’t be restricted.

Security flaw in WordPress

Security Flaw in WordPress: A Flawed Email Confirmation Feature

Introduction:

WordPress introduced a feature in version 4.9 requiring an email confirmation link to change the site email address. While this feature aims to enhance security by verifying that the user has access to the new email address, I argue that it creates confusion and weakens security in certain contexts, particularly in single-site WordPress installations.

Purpose of the Email Confirmation Feature:

The idea behind this feature is to ensure that the person requesting a site email change can access the new email address, preventing SPAM, reducing mistakes, and confirming that the email is active. This pattern is widely used in platforms like Facebook, where a confirmation email is sent to verify identity before account changes are made. However, in WordPress, the implementation of this feature—especially on single-site installations—introduces more problems than it solves.

Issues with the Current Implementation

1. Confusion Between Roles in Single-Site vs. Multisite Installations:

In a multisite installation, there are two distinct admin roles: super admin and regular administrator. These roles have different capabilities, making the email confirmation feature somewhat logical. The super admin has authority over the network, while regular admins manage individual sites. However, on a single-site installation, there is only one type of admin, and this feature introduces unnecessary role confusion by implying there are two distinct roles: an “installing admin” and a “post-install admin.”

This distinction doesn’t apply to single-site installations, where all admins have the same capabilities. The requirement for email confirmation adds complexity, making it harder for admins to understand their permissions. It also creates an inconsistent experience between single-site and multisite installations.

2. Arbitrary Code Execution Makes the Feature Pointless:

In WordPress, admins can run arbitrary code, giving them unrestricted control over the site. This means an admin can bypass the email confirmation process by simply running code that changes the site email. As a result, the feature gives a false sense of security. If an admin has the power to run code, the system shouldn’t impose an artificial restriction that they can easily work around. The current implementation pretends to enforce security, but admins can still override it.

3. Transient Data Exposure and Security Risks:

During the email confirmation process, the old and new email addresses are both stored in the database, potentially for a long period of time. This creates a window of vulnerability where sensitive information could be exposed, especially if backups are taken during this transient period. Storing two email addresses for no clear reason seems like an unnecessary security risk.

4. Inconsistent Logic for Admin Roles:

The feature assumes that admins need to confirm email addresses, but this is inconsistent with how other admin actions work. For example, when an admin creates a new user, they can skip sending a confirmation email. This inconsistency makes the email confirmation requirement for site email changes feel arbitrary and out of place. If email confirmation is necessary for security, why isn’t it applied to more critical settings like the site URL?

Fundamental Flaw: False Security in Single-Site Installations

The core issue with this feature is that it doesn’t make sense in the context of single-site installations, where admins have equal power. The process of confirming the email doesn’t prevent admins from making changes if they can run arbitrary code. This false restriction can confuse admins, leading them to believe they are limited when, in reality, they are not.

Additionally, WordPress allows users to install the platform without outbound email access. During installation, the site email can be set without confirmation, but after installation, the same user is blocked from changing it without email credentials. This inconsistency makes the feature feel more like an oversight than a security enhancement.

Encryption Problem: Non-Standard and Insecure

One significant concern is that the encryption method used for the site email confirmation link is a custom MD5 hash, which is weaker than the standard WordPress nonce system. This inconsistency introduces potential security vulnerabilities, as custom solutions are typically less robust and harder to maintain than standardized approaches. The user email change system, for example, uses the nonce system, which is extensible and more secure. Why wasn’t the same method used for site email changes?

Conclusion: A Poorly Implemented Design Choice

This email confirmation feature in WordPress 4.9 was likely added with good intentions, but it introduces more complexity and confusion than necessary, especially for single-site installations. The reliance on email confirmation for a setting that an admin can bypass with code creates a false sense of security. Moreover, the custom encryption used is less secure than standard options available in WordPress. While preventing typos in email addresses might be a reasonable goal, the approach taken is overkill and creates more problems than it solves.

In conclusion, this feature should either be rolled back or significantly rethought to align with WordPress’s actual user roles and security needs. Admins with the ability to run arbitrary code should not be subject to artificial restrictions, and any system that claims to enhance security should not introduce new vulnerabilities in the process.