Thus far I’ve spun up two potential features-as-plugins proposals for WordPress. One refactors the
get_template_part() functionality to be object-oriented. The other adds a password-less authentication method for XML-RPC to better protect the interface (and users’ passwords).
Neither has seen much traction, so I’m going to stop writing code and propose ideas first. 1
Today’s proposal is for a SUDO-like mode for WordPress.
What is SUDO?
For those of you who don’t spend a lot of time around hardcore sysadmins, SUDO is the ability to run commands on a Linux system as another user (usually the root user). It allows you to provide user-level access to multiple people without granting them a privilege level where they could potentially destroy the system.
If you’re on Mac, this is like the prompt that requires your administrative password before you change a system setting. On Windows, it’s like running a program “as administrator” because it has system-level access.
SUDO helps hide higher-level functionality behind a privileged login or double-password-login wall. It’s a security system to protect you from yourself.
Why do we Need it in WordPress?
Just about all of us log in to our site as an administrator when we’re logging in to write. This is a problem.
Administrators are like the root users on Linux. They can do anything. They can activate/deactivate plugins, change themes, change permalinks, install plugins, edit plugins, and modify every setting possible within WordPress. If you’re logging in to write, then logging in as an administrator is overkill.
Yet few of us use Editor-level accounts to write.
If you’re blogging from a coffee shop or another unsecured wireless network, and you don’t have an SSL certificate set up for your site, then anyone with a network-monitoring application can see your cookies when you’re on the site. Another person could then steal your cookie and visit your site as you. If you’ve been logged in as an administrator, then they now have 100% access to the inner workings of your site.
A security best practice is to have one login for editorial purposes (i.e. your day-to-day user) and another for administrative purposes (that you only use when on a trusted network). I use this setup on many of my sites. 2
This setup, while it works quite well, is a major pain. Huge chunks of WordPress are available to administrators alone. Many plugin developers, working under the safe assumption that site owners are always logged in as administrators, lock their settings pages down to admin-level users as well. On some of my sites, I’ve had to choose between two workflows:
- Draft my posts with an editor-level user and publish them at home from my admin account after I’ve had the chance to finesse various plugin options for the post.
- Hack the plugins so editorial features are visible to editors and maintain a private fork on BitBucket.
Neither of these workflows are maintainable on the long-run. We need a better option.
SUDO in WordPress
Instead, I propose a SUDO mode in WordPress.
We would keep the usual editor/administrator user-level setup, but expose a flag for non-administrators to grant SUDO access. These users would then be able to log in as usual and can optionally provide their password to achieve a time-limited admin-level session.
One possible approach would be:
- Log in as an editor
- Click a menu item to enter SUDO mode
- Enter a 1-time password from a 2-factor auth tool like Google Authenticator
- Be given administrator-level access for 5 minutes (with a persistent timer shown in the admin)
This would make it easier for writers used to admin-level access to still make higher-level admin changes without exposing a persistent auth cookie when making requests. It would also force writers to make a conscious decision to do something as an administrator.
Using a 2-factor auth tool will allow us to drastically limit exposure to replay attacks (Google Authenticator passwords are only valid for 30 seconds) and helps further secure admin-level functionality by requiring the second factor. Limiting the time for which admin-level access is extended will likewise limit exposure from having a cookie stolen and spoofed over the wire.
SUDO-style access would be a perfect fit for a plugin because 2-factor authentication should always be optional. That said, eventually rolling the plugin into core (again, making SUDO access an option for non-admin users) will help promote tighter security in the community as a whole.
Is it Useful?
How far would this go to secure WordPress, exactly? Would people actually use it? Would our sites benefit from such an implementation?
I would argue yes. On my servers, I disable remote root access (meaning you cannot log in as root and must log in as another user and use SUDO) and log whenever anyone uses SUDO for anything. This helps me a) lock out anyone trying to SSH as root from the beginning and b) keep track of everything done on the server with admin-level access.
I would love to have this kind of security configuration for every WordPress site I build. I’d be willing to build it myself, but I also want this kind of functionality in core.
Do you see a benefit from the above proposal? Would you use it on your site? How would you approach SUDO in WordPress differently?
- Both of these ideas were proposed as blog posts or on Twitter before I wrote any code. Everyone who saw it claimed it was a good idea, so I sunk a few hours into fleshing out proof-of-concept plugins, only to have supporters abandon things later. Considering neither is listed as a potential feature-as-plugin on the make.core site, I’m going to stop writing code for potential features until I get buy-in from the core team. Frankly, I don’t have the time to waste writing architectural changes for WordPress that the core team doesn’t want to support. ↩
- I’ve actually had someone steal my auth cookie when I was blogging at a coffee shop before. All they did was log in to create a private “I hacked your site at Starbucks” post, but it was enough to scare me into truly caring about security. If it can happen to me, it can happen to you, too. ↩