The Case for 2FA by Default for WordPress

Administrator panel compromises are one of the most common attacks that everyday WordPress website admins face. We work with thousands of clients who have encountered attacks on their websites and I’ve long ago lost count of the number of times that I’ve told clients that the point of entry was their WordPress login page. Brute force attacks and compromised administrator users are overwhelmingly the most common attack vectors for the CMS platform, which as of 2022 makes up over 40% of the entire web.

WordPress has many security plugins and extensions that can greatly improve security but the responsibility is on the website administrator to install and configure it themselves. Security is not something that website admins typically want to deal with from the get go, it usually ends up forgotten and is sadly often left to be dealt with only after a compromise has taken place.

I would like to make the case for multi-factor authentication by default or at least as an immediate post-install option for the most popular CMS platform that powers the web. This would not be an unprecedented move and would just follow what the web has been doing for years which is to make the web more secure for everyone.

Default Configurations

There are a few major default configurations in WordPress that renders it at risk without the use of additional security plugins or a website firewall. Namely:

The admin panel login page is wide-open to anyone on the web
There is no limit on failed login attempts
There is no multi-factor authentication
By default the “Display name publicly as” option is the same as the username unless the first name is also filled which helps the attackers

All together this creates an environment highly prone to brute force attacks.

A standard WordPress login page, open for the world to see

A Predictable Formula

Taking this into account we’ve seen some very predictable behaviour from attackers. A typical WordPress compromise will go something like this:

Brute force their way into the WordPress administrator dashboard
Install a file manager plugin
Upload a backdoor or webshell
Drop their payload

It’s all very simple, and a great number of these compromises can be avoided with some very simple changes to the environment.

Security Plugins to the Rescue

We’ve written before on how to improve the security of a WordPress environment. There are many different security plugins and services that can make a website less prone to these sorts of attacks. Many are free of charge, but none of them are included in a default WordPress installation.

Automattic, a large contributor to WordPress, has a great open-source plugin called JetPack that addresses a number of the default configuration issues that I described above. It is used by over 5 million websites, and gives website administrators the options to:

Enable multi-factor authentication
Mitigate brute force attacks

However, JetPack is not included by default in WordPress and needs to be installed and configured by the administrator. The only two plugins that are present by default in a fresh WordPress install are:

Hello Dolly
Akismet (anti-spam)

The Akismet plugin inclusion was an attempt to address chronic problems of comment spam that WordPress admins deal with on a daily basis. Akismet has been included by default in all WordPress builds since version 2.0 (released in 2005) but as of yet no such action has been taken to push users toward 2FA.

Not Unprecedented

Security can be a nuisance, and people often tend to avoid it unless they are forced into a situation where it can no longer be ignored. Adobe’s ecommerce CMS Magento has faced similar issues with brute force attacks and other security issues. In 2020, they released patch 2.4.0 where they took some steps to address the very same chronic security issues that plagued the platform for years:

Multi-factor authentication by default
Randomised admin panel URL
Removal of standard “admin” user

Readers brave enough to have attempted to install Magento 2 from scratch will know that during the initial installation process 2FA is enabled automatically and a randomised string is generated and provided to the user to access the admin panel. Both of these can be changed after the fact if the admin so chooses, but they are initially included whether they want it or not.

WordPress has changed some default configurations before, and have thankfully also removed the standardised “admin” user name, but haven’t yet followed suit on the other two points.

Concerns About Lock Outs

We did reach out to the WordPress.org team to hear their thoughts on the matter. It sounds like this exact issue has been discussed before as far back as 2015. There are some valid concerns about ease-of-use and end-users getting locked out of their dashboards:

I’ll say it this way: We want users to be able to secure their sites with 2FA, not sit back and watch outdated abandoned sites pile up because they locked themselves out and simply give up when … we mention FTP, Database, or SSH.

Part of the WordPress philosophy is to have things work “out of the box” and create as few roadblocks to ease of use as possible. Keeping to these core tenets is one of the reasons why WordPress has been so resoundingly successful.

However, creating as few roadblocks as possible is a two way street: It also means you are creating fewer roadblocks for the attackers as well. While on one hand there may be abandoned sites due to lockouts, the alternative is that those very same sites are instead being compromised and used to spread malware. Even if a user gets locked out of their admin panel it’s easy enough to reverse that or (temporarily) disable 2FA to regain access.

Could it not be said that the chronic issues of brute-force attacks and compromised administrator panels are themselves at odds with the “ease of use” philosophy, even more so than simple 2FA?

In Conclusion

Most people do not want to worry about security until it’s too late, and some very simple changes to default configurations in the WordPress platform could make far fewer people find themselves in that situation to begin with. The best part is that the tools are already available, they just need to be implemented.

The 2FA feature in JetPack is integrated with wordpress.com (rather than wordpress.org) so some adjustments would need to be made to the plugin to keep .com and .org rightfully separate, but that should be well within the realm of possibility. There are also other 2FA plugins available that could be used for this purpose instead.

The good folks at WordPress made Akismet part of a default WordPress installation to deal with chronic comment spam. They could also do the same with their JetPack software (or some other multi-factor authentication plugin) and have 2FA and brute force protection enabled by default. I might also recommend that they include random admin URL generation among the great feature set that it already has, and it should be included in the initial WordPress installation process, much like Adobe’s Magento platform.

Even just a simple post-installation suggestion on enabling 2FA would make a huge difference.