Sometimes it’s too easy as our hacker sits in her darkened room, waiting… His target was on the site and was typing in characters P…A…S…S…W…O…R…D…1…2…3 

Excellent! Now on the actual site, our bad actor logs in – yes – admin password123 and in! The phishing attack worked just as he had imagined and now total access to the WordPress site was hers; what would she do.

With the start of the new decade I thought I would take a look at some of the basics of WordPress security that we often take for granted and consider how in 2020 we can achieve a minimum level of security that aims to remove 99% of automated attacks.

This article is less a “how to”, rather a look at user management strategies for agencies and sites. With the right strategy in place you can rest assured your users only have access to things they need and are keeping their and your secrets safe.

User Management

What is a user?

For the purposes of this article a WordPress user is someone who has a row in the WordPress users table in the database. As such a WP_User object can be generated and they have a set of capabilities within WordPress core. That might sound a bit technical, but this means a user is someone who under normal circumstances can access and login to wp-admin and perform some sort of action.

A user normally has a login username, a password, and email address. In addition they might have one or more roles. They have additional profile information which is stored in the usermeta table.

Users probably represent squishy humans in the system, most WordPress users will be active through the WordPress admin areas, though not always. 

So with users defined, let’s look at how we stop them running amok and changing everything.

Understanding WordPress Roles and Capabilities

WordPress Access Control System is based around “capabilities”. A capability is assigned to a user and then that can be tested against, by the code. By default WordPress has a bunch of different capabilities from editing plugins to publishing posts. Most actions within the WordPress Dashboard have a capability check making sure you are allowed to take the action you are doing.

Capabilities can also be added by plugins, so for example if a plugin has a shop interface then the plugin can define a capability view_orders and then test against that capability when viewing the orders page; only a person with that capability can see the page.

It’s important to understand, if a plugin or feature is not checking for the capability then it’s capable of being run by anyone; a lot of poorly coded plugins assume because you have access to the admin area you must be an admin.

Every user has dozens of capabilities. So why do people not see all these “capabilities”? Well to simplify everything WordPress has “Roles”, roles are just a collection of capabilities collected together. When a role is applied to a user, that user gains the capabilities associated with the role.

By default WordPress comes with the following roles:

• Subscriber
• Contributor
• Author
• Editor
• Administrator
• SuperAdmin

While these progressively gain more capabilities, they do not build on top of each other so it’s not a case that the editor role is the author role + extra capabilities, even though it does have the author role default capabilities plus additional ones. 

Additional roles can be added and removed, and even the default roles can be removed, though admin and superadmin have specific checks that they return when WordPress gets updated.

Speaking of superadmin, it’s the role you are least likely to have heard of, of the default WordPress roles, as it only appears when the site is defined as a Multisite. Users with the superadmin role have the ability to access and manage the network aspects of multi sites.

So, a role is simply a holding bag of capabilities which can be applied to a user. Individual users can still have additional capabilities added or removed on a per user basis. Also, while the default UI only shows one role per user, a user can in fact have multiple roles.

To summarise

A user can have any capabilities and multiple roles, but those roles might not reflect the capabilities the user actually possesses. If you run a WooCommerce site or a large membership site, or just have lots of subscribers, you might have just nervously twitched. 

The good news, we have a list of roles, we know the capabilities they should be giving to a user and therefore auditing users is as simple as looking at their capabilities and comparing.

Of course if I really wanted to hide a user’s capabilities rather than then modifying the actual user, you would use the 

function innocent_function($allcaps, $cap = false, $args = false)
{
    $allcaps['edit_posts'] = true;
    return $allcaps;
}
add_filter('user_has_cap', 'innocent_function');
user_can(3, 'edit_posts');

user_has_cap filter, to simply return “the user has those capabilities”. So we need:

• To list all our users and what capabilities they have, along with what roles they should have
• To compare it to the capabilities a role should have
• As well as making sure within our codebase nothing is filtering the user_has_cap filter.

Up to this point we have been making an assumption that actually people are using different roles so while auditing your users’ capabilities is a useful exercise and one to do for the basics, we need to:

• Check “should that user exist”?
• What role should they be?

Should the user exist

Philosophical issues aside, in this case we are concerned solely with “should the user exist” within the context of your website.

A few questions to ask yourself when evaluating the need for this user

• Are they still employed by/work for or with us?
  Sounds like such a simple question, but you will be amazed how many companies have an onboarding policy including giving site credentials but don’t have a leaving policy that removes them. It’s also not just your company but those third party agencies; do you still work with that SEO agency? What about the web designer?
• When was the last time they logged in?
  So there are some people who on paper should maybe have access but when was the last time they actually logged in? Setting a period at which if you haven’t been logged in over the last 6 months we remove/deactivate/contact your line manager probably makes sense. This review should be for everyone.
• Does the role need a user?
  I mean does everyone in the company need a login to the site? Did you once upon a time have a grand plan where everyone in the company would blog? Yeah, you and every company, the reality is very few folks actually need a login or interact with the site. Even if they DO write blog posts, do they edit and publish them, or is that handled by someone else? If all they are doing is login, hitting Add New and copy and pasting from a Google Doc, do they need a login?
  Worse, are you giving them a login just to provide an author bio? If so, good news; there are plugins for this https://wordpress.org/plugins/guest-author/ https://wordpress.org/plugins/molongui-authorship/

In addition, if you run an e-commerce or membership site there is a good chance it creates users. Have they bought anything in a while? Could you set a policy if you don’t login every x months we remove your account? Especially for membership sites, you might very much want to remove expired accounts after a given period. 

What role should they be?

So having decided the user should exist (how kind of you). Now you need to determine what level of access they need. In most websites there is one “default” user, and that is administrator. Sure the other roles exist, but most companies just make everyone an administrator and that’s it.

Needless to say almost no one needs to be an administrator day to day.

Let’s take a look at the different roles and their potential use case

Subscriber – This role gives you access to the admin area, to your user profile, the dashboard and any functions/tooling that is checking if someone has access to the backend but not specific capabilities. As a role it’s not meant to be able “to do” anything other than be a profile and access content. It’s often used as a role for members to a site. Other uses might be ex-employees where they don’t want to reassign posts or indeed, an account for Guest Authors, where they can create a profile, and then their post is assigned to them by the editor. 

When might you use this role:
This is a horrible role; if you have lots of users in this role you have a massive amount of potential targets and while it feels like a role that can’t do much harm, it’s allowing a user, which you inherently don’t trust, onto the system and gets them at least part of the way to becoming a hostile actor. It also generally has little to no purpose as things like the “guest author” plugins above can easily replace most of its use cases.

Capabilities Assigned from this role:

• Read – checked when trying to access the dashboard, user profile 

Contributor – This role lets you login, access the posts option to write posts and delete posts that are in draft and owned by that user. Importantly, while they can edit their own posts they cannot edit others nor can they publish a post.
When might you use this role:

It is quite feasible that for most sites contributor is the default role, especially if the site has any sort of editorial process where posts are proofed, SEOified, etc. In a content generating role it doesn’t hugely affect the capabilities of the user and still lets them build things even with block editor. They can use reusable blocks, but they don’t have the ability to create new ones or delete them. One area they cannot access is other post types beyond “posts”, and that includes pages, unless explicitly declared. The biggest potential limitation is the inability to upload files via the media uploader.

Capabilities Assigned from this role:

• All from Subscriber
• Delete_posts – their own posts but not once published
• Edit_posts – their own posts, including creating new posts, but they can’t publish or adjust the state of the post.
• read_reusable_blocks – read blocks created from everyone 

Author – This role lets you login, access post/pages option to write, delete and publish your posts. You can edit and control your own content; you are not able to edit other people’s content. Within the block editor you can also create, edit and delete reusable blocks. By default authors have access to both pages and posts.

When might you use this role

Like contributor this is quite feasible as the default role, and suitable when the user is going to manage their own editorial content. If they are not the person who will hit publish then contributor is a better choice. 

Capabilities Assigned from this role:

• All from Contributor & Subscriber
• Delete_published_posts – delete posts they are marked as author of
• Edit_published_posts – edit posts they are author of, once published
• Publish_posts – publish a post
• Upload_files – upload content via media library
• Create_reusable_blocks – create reusable blocks
• Edit_reusable_blocks – edit blocks they have created
• delete_reusable_blocks – delete blocks they have created

Editor – This role is the last of the content roles and is the same as the author role, except they can make changes, create, and delete pages that are authored by someone else. They can also change the authorship of a page.

When might you use this role

The day-to-day manager of the site’s content creation and any editorial team probably want this role. While it’s unlikely to be the default role for all users on the site it’s not unfeasible that multiple individuals will have this role.  This is the last of the low risk roles. The higher roles all come with a stark escalation of privilege. If a site used to historically just have admins, reducing those users to editors will not change how they use the site too much.

Capabilities Assigned from this role:

• All from Author, Contributor, Subscriber
• Delete_others_pages – delete any page
• Delete_others_posts – delete any post
• Edit_others_pages – edit any page
• Edit_others_posts – edit post
• Manage_categories – add/remove categories
• Manage_links – blast from the past, but WordPress used to have links “postesque” type thing that’s no longer a thing, but might be depending how old your site is.
• Moderate_comments – see/approve/delete any comment
• Unfiltered_html – switch to HTML view, and be able to paste HTML into posts/pages and not have it filtered. By default, authors have limited options, so couldn’t add script tags for example.

Administrator – The admin role gives full access to managing the site, including access to edit settings and plugins on a non-multisite site. This is the “I have everything and can do everything” role! MUHHHHAAAAAA! As such it’s normally the role everyone ends up with. As this gives you access to do everything, including run arbitrary code via the code editor and plugins interface, it’s a high risk role that should be limited. The admin role also is the role that is allowed to create other users.

When might you use this role

You do need an admin (well you don’t but that’s a story for another day) to do all the things that admins are needed for however only people who are charged with maintaining the site should have access. 

Capabilities assigned from this role:

• All from previous roles discussed
• Activate_plugins – activate a plugin from the plugins screen 
• Edit_dashboard – change the widgets shown on the dashboard
• Edit_theme_options – edit theme options in customizer
• Export – run the XML export under tools
• Import – run the XML import tools NOTE both export/import the tools are now plugins, but the capability is still in WordPress core.
• List_users – see all users, and click into their user profiles.
• Manage_options – gain access to the WordPress settings page
• Promote_users – change the role of a user note while it says promote, its to change a users role.
• Remove_users – delete a user
• Switch_themes – change the theme
• Customize – see the customizer

In addition there are some extra permissions if on/or not on a Multisite

On a Multisite setup:

• Delete_site – you can delete the single site, but not the multisite

On a Single site setup:

• Update_core – update the WordPress core files
• Update_plugins – update Plugins, and their language pack
• Update_themes – update Themes, and their language pack 
• Install_plugins – install a plugin via the upload option and either searching wp.org or uploading the zip
• Install_themes – install a theme via the upload option, either through wp.org or uploading the zip
• Delete_themes – delete the files from the server
• Delete_plugins – delete the files from the server
• Edit_plugins – use the code editor to edit plugins
• Edit_themes – use the code editor to edit themes
• Edit_users – change user profile information for users
• Create_users – create a new user with whatever the default role is within the WordPress settings.
• Delete_users – delete a user
• Setup_network – create a multisite network (if defined in wp-config) – note once done the first time, this is then mapped to superadmins.

SuperAdmin – Only available on a multisite, these admin users have the ability to add/remove sites along with the capabilities of a normal administrator. On a multisite install the admin role is a reduced role and so loses some capabilities which only the superadmins have.

When might you use this role

Well it’s only available for multisite, beyond that the criteria is that of the admin user.

Capabilities assigned from this role:

• Create_sites – create a new site in the network
• Manage_network – access the network tab
• Manage_sites – change site settings in the network tab
• Manage_network_users – manage which users can access which site
• Manage_network_plugins – set a plugin to be globally active/installed
• Manage_network_themes – set themes to be available or indeed installed
• Manage_network_options – set sites’ settings that are global
• Upgrade_network – access the upgrade network option

Ok, so what roles should you actually use?

For people writing content, the most obvious roles are contributors and authors, however for many the limitations in allowing uploads to contributors means that most sites, while starting with contributors, will end up giving their staff author roles.

For people editing content, then the editor role is the obvious choice, for one-man sites and smaller sites you may end up with the default role being an editor.

People needing admin level access should be restricted. If you are currently working with a site with lots of administrators then a simple test is to reduce everyone’s level to editor, and see who complains. When someone has an issue, ask them what they were doing and see if this task was appropriate. For a few people they will need to have the higher level of access and you might wish to bump them up.

If you have people who write/edit lots of content but also do site maintenance, for example you might be the solo person, then consider having two accounts and using the “fast user agent switching” plugin to move between them. Set one account as an editor and the other as the administrator. Then you login as your editor, and use that unless you have to use the admin account.

Tims Tip: If you do have two accounts, I like to make my administrator account admin colour scheme red, so I recognise this is the admin account and I’m less likely to use it for day to day tasks.

Creating your own roles

Roles are just a name and a collection of capabilities and adding your own is easy either through WP-CLI or with a plugin. Common roles I have set in the past:

Staff Contributor – The same capabilities as contributor but with the capability upload_files. This does significantly increase the danger posed by this role, but as is always the case the risk outweighs convenience. The alternative would be authors and while this role is less about outright security and more editorial workflow it seems a fair tradeoff.

Site Manager – Editors with the create_user capability giving them the ability to add default users, you probably also want them to be able to delete users. I have in the past written custom code that checks custom capabilities to make sure they can only delete /add/promote up to site manager level. I would also consider adding theme_options and customizer access to allow them to edit widget, and menu level content.

Super dooper boss – A standard editor role to give to anyone who complains they should be an admin, who clearly doesn’t need to be, but you can’t risk your job upsetting – aka your boss.

It’s also worth noting plugins add their own roles, for example WooCommerce has:

Customer Role – is the same as the subscriber role with only the read capability.

Shop Manager – has the same permissions as the default editor role in addition to two new capabilities manage_woocommerce and view_woocommerce_reports. It’s worth noting that, at time of writing, while the documentation for WooCommerce says it has the same capabilities as an editor, this role hasn’t been updated for Gutenberg, so a shop manager can’t, for example, use reusable blocks even though an editor or even a contributor can.  So when creating your custom roles that replicate WordPress ones be mindful you will need to maintain them.

Other plugins also add their own roles, and some plugins often extend existing ones, again, for example, WooCommerce adds the manage_woocommerce and view_woocomerce_reports capabilities to the admin users.

So, users’ capabilities and roles

Access control is managed via capabilities, and specifically the has_cap function within the WordPress user object. Users gain capabilities by being given a role or by an individual capability being added to their user role. Even if they don’t have the capability of a theme or plugin, they may be able to override such checks for good or ill.

A role is simply a collection of capabilities, users normally have a single role, but that’s just because that’s how it’s set in the WordPress user interface and in reality users can have multiple roles. Indeed plugins like BBPress specifically set multiple roles.

When choosing roles, select the role based on what the user is going to be doing, not what they think they need. Every user thinks they need to be an administrator when rarely they do. Try to give the least amount of privileges.

If needs be, custom roles can be created to suit your setup but remember you must maintain such roles. Because roles are just a collection of capabilities, if a new release of WordPress came out with new capabilities your custom role will not have them. 

Consider adding your custom role as a secondary role, so you’re just applying your additional capabilities. The downside to this is currently there is no real UI for this type of style, so would need custom code, or heavy use of WP-CLI.

Audit your users regularly; users that haven’t logged in or who no longer need access should have their accounts removed.

Consider creating second admin accounts, for users who need them, that they can switch into maybe using the “fast user switching” plugin. Try to avoid using the site as an administrator.

Protecting users

Up until now we have concentrated on users as a collective, and looking at how we restrict what they access. Now we are going to harden our users’ accounts to try and prevent those accounts themselves from being compromised.

Passwords

Most people start off life with one password, it’s normally fairly simple, we joke and snigger at password123 but even the most mighty of tech firms probably has a test server setup somewhere with something considered insignificant with that password. Regardless, the password is simple and memorable: a daughters name, favourite football team. Over time the password gets reused, and some sites have requirements, and so the password evolves a capital letter at the start, a number added to the end and pretty quickly we go from Bernard to @Bernard123. Let’s face it somewhere we all still have that password.

Then something happens, a scare, maybe it was a site got compromised or your tech friend came and muttered at you. You started to realise one password was a mistake, you start to add more @Bernard1234 …5 …6. This quickly becomes more complex so you come up with your first cunning system the site name+the year you signed up+if you stood on one leg. It’s foolproof but then you start forgetting things and oh my.

At some point, reset password becomes standard, indeed you might start thinking why have passwords at all, just get them to send me a reset every time.

If that sounds like you, don’t worry you are not alone, but for many of your users they might be part-way through that journey and that’s fine but we need to shortcut them to the end quickly.

With passwords there really are only two sensible approaches that I have come across –  passphrases and password managers.

But before looking at either it’s important to understand the rules of a good password and they are:

• Make them long
• Don’t tell others
• Make them unique

The longer your password is, the stronger it is. We have been trained to add capital letters, numbers, special characters and these are helpful but the key to a strong password is making it longer. If we take the following a£Dq2@ vs fqkoafyp – which is stronger? Clearly the first –  nope that’s 6 characters vs 8 and even with the extra character sets the 8 character password is going to be harder to crack.

The second rule, “don’t tell others”, can be often misunderstood. Keeping your password secret means don’t print it to your screen, and don’t share your login with someone else. It’s yours, guard it as such.

Make them unique, every site should get its own password, so if it’s compromised your accounts on other sites are not compromised.

WordPress Password Strength meter and changing the password

When you click create new password in your, or another user’s, profile, you are not presented with an empty password field rather a pre-generated random password and a strength indicator (which with the generated password should always be green). You can overwrite this password with a password of your own, or accept it and proceed.

The password strength meter itself is based on the zxcvbn Library originally built by Github and Github blog [https://blogs.dropbox.com/tech/2012/04/zxcvbn-realistic-password-strength-estimation/] has a good explanation of how it works.

I have little to add to it, except to say only accept strong passwords. By default WordPress will allow you to still proceed albeit by making you tick a box with a weak password. So look to enforce password strategies; lots of WordPress security plugins come with some sort of password management features.

Passphrases

A passphrase is 4 or more randomly generated words strung together. The idea is to make a phrase, ultimately, instead of remembering a complex password. You simply need to remember 4 words, which is a lot simpler. If you add in special characters, all the better. Passphrases were popularised by the XKCD comic but have been a pretty standard practice for a while. 

Passphrases still need to be unique so each site would need its own 4 random letters and those words should be random, though there are a plethora of generators out there including some WordPress plugins that will generate XKCD style passphrases. Don’t try to pick words yourself as humans are terrible at random.

Password Manager

Once upon a time password managers were frowned upon, these days even the most purist security professional will suggest using password managers. A password manager is simply a tool or service that stores passwords in a vault, which only you can access. The idea being that you generate a long password, which you never have to remember for the site, store it in the vault and when you need to login, you copy it from your password manager (or your password manager auto-fills) and you login.

With a password manager, you need one passphrase to access all your sites. So why were they once upon a time frowned upon? Well a password is something you know, while technically a password manager is something you own. If you have a weak or non existent password protecting your manager or the vault gets compromised then the whole thing breaks down.

What’s more, in the early days password management services had issues with themselves being hacked and I don’t think any major password management service hasn’t had some sort of breach. That’s not to say passwords were compromised, simply they are huge targets. When it comes to password managers pick one you like and run with it, I use BitWarden having used KeePass for many years, but there are plenty of services including 1Password and LastPass; both have good reputations.

Browsers, like Chrome, have also started offering password management services, though be careful that when picking a password manager you can get it on all the devices you are planning on using.

My Own Strategy for password management

I use BitWarden as my password manager and virtually all my passwords are kept in there, with the exception of one or two which are passphrases, specifically my primary email account and the place where a lot of my reset keys go. This means the number of passwords I need to manage is relatively low, just device specific logins, password manager login, SSH passphrase for my primary key, though for other keys I now store them in my password manager and email.

Setting sensible passwords and education

So as an admin you should, at minimum, be using long, unique and secret passwords and ideally be enforcing use of secure passwords across the board. 

In the perfect world you would set the minimum character length of WordPress to 12 and make sure all passwords are strong. With plugins this is a few clicks away, however the reality is without an accompanying education programme this is just going to lead to  massive negative user feedback resulting in the policy quickly being revoked.

Password management is not about setting the policy, it’s about educating users. 

Educating users by leading by example and explaining needs without recriminations. A good option is to check and validate passwords, compare passwords with known password lists and automatically prompt, if the password is found, for it to be changed.

Consider language changes, the very term “password” can be changed to “passphrase”.

Maybe look at introducing company purchased accounts for password managers, this doesn’t mean buy a single account but as part of the onboarding process offer a password manager. Though be flexible, if people already use a password manager, don’t force them to use the company prefered option. Likewise if the company is purchasing password managers, consider how you will offboard people who might have stored non-work passwords in there.

If you make the process simple and reduce the fear aspects, passphrase or password management usage will shoot up. Ultimately leave your special characters, and changing passwords every 6 months, at the door and concentrate on “keep it long, keep it safe, keep it unique”.

Passwordless authentication

Rarely are passwordless systems actually passwordless rather simply relying on someone else’s passwords.

Single Sign On Systems

For larger enterprises and even smaller clients, perhaps using Google Suite for email will already have an authentication system and integrating such a single sign-on will reduce user friction. In such scenarios the site normally hands off the authentication to the sign on system, then if authenticated it passes them back and the user logs in. SSO systems either work by totally replacing the user management, or just providing a way for the “local”, in this case WordPress user, to login in addition to their normal login procedure.

The downside to a SSO is they are normally complex to setup and manage, so outside of enterprise clients where they might already have an LDAP or Active Directory setups, spending the time to build such a system is a pain. Worse, while plenty of services will integrate with your SSO setups, they nearly always do so only in their more expensive enterprise plans, so to make full use of such systems can prove costly.

Magic Links

There are multiple plugins that provide “passwordless” systems all that work on roughly the same principal. The user “logs” in and the system sends them a link to a communication system, normally email but some might send it to Telegram/Slack and the user either clicks the link or enters the code. The system then considers them to be authenticated and you can login. It’s similar to two factor authentication mechanisms but with what would normally be the second factor considered the primary. 

The big advantage of Magic Links is they are simpler for the user – no passwords, no needing to remember things – but they break the paradigm of a password being something you know, and rely on your owning and being able to access something, be it Slack/email etc. Also, while unlikely, this method also risks the potential of being intercepted during transit. There are a few examples for WordPress and they all have their benefits and drawbacks and while I have yet to be persuaded that they provide an effective login mechanism they open up conversations we should be having about how to make things seamless. 

Biometrics

Biometrics, especially on phones, has seen a popular rise, be it a fingerprint or face scan, and there has been some work to bring these tools to the web. This is a very young industry and tooling is still fairly immature, at least for the web, so in terms of securing my site I would be nervous about such usage. But if you are considering a biometric system I will leave you with this thought, if a site gets hacked, my password is compromised, I change my password; who pays to change my face?

Two-Factor Authentication

In many ways getting people to select good passwords is quite hard even with education, and indeed with “keep it secret” we can only do so much to judge the effectiveness of our education. 

Likewise there are lots of social engineering tactics for clients to reveal their passwords, to the point we cannot simply rely on them alone to protect accounts. Enter two-factor authentication, sometimes called multi-factor authentication.

The concepts of multi-factor authentication (and there is a subtle difference between two- and multi- factor authentication) is that you have to pass multiple challenges before being allowed in. One factor is a password, or maybe a thumbprint or face scan, while another might be a code sent to your device. The combination of multiple factors means there is a high probability it is you. 

Two-factor authentication normally refers to the very specific paradigm of password and second authentication method, normally a code generated on a device (such as a code generated by the Google Authenticator app) or a physical key. 

There are few people who would say don’t use two-factor as standard where available, yet I suspect many people giving that advice might not be implementing it. Indeed I wonder if you, reader, have uttered those words. You might even have two-factor setup on your email, what about your Slack? 

Two-Factor Authentication for WordPress

There are a range of options; I have long recommended just a single plugin – the “two-factor authentication” plugin. It’s written by the WordPress security team, offers support for TOPT (time-based one-time passwords), as well as support for U2F and other mechanisms. 

How does this work in practice? You can install the plugin, then your users can choose to implement a 2fa option. If they choose the TOTP option, which will be the most popular, they will need a TOTP supporting client on their phone or machine. The most common is the Google Authenticator app but others do exist (including LastPass, Microsoft Authenticator, Authy).

With the Google Authenticator app installed on their phone, they will scan the barcode in their user profile and from then on be prompted on login to provide a second factor.

Other options include a hardware token. I have talked about my hardware token of choice before but again there are plenty of options.

Advice for Two Factor Authentication

• Implement it, and make it a requirement for all members of staff, but at minimum anyone with admin roles. 
• If you have the budget consider hardware tokens for everyone over going down the app route.
• Most two factor apps offer backup codes, make sure you are storing them somewhere safe, but ideally not in your password manager. After all the whole idea is to have a second factor.
• Try to enforce 2FA across all apps within your systems, but stick, where possible, to a single approach; if you need multiple apps/devices then people start taking shortcuts.

With a secure passphrase and 2FA enabled it will be very difficult for a bad actor to get into the account without significant effort through the main login. Just remember there are multiple routes to authentication for a user including XML-RPC and REST API so just because the dashboard is setup requiring 2FA doesn’t mean other areas are as well.

General user hardening

Phishing and Spear Phishing

Increasingly WordPress sites and users are becoming targets for phishing attacks. A phishing attack is an email or other communication pretending to be genuine that is used to lure you to take an action on your site or a fake site pretending to be yours. 

Example Phishing emails include:

• Your site’s database needs updating,  please click here
• There has been a critical error please click here

In most cases they replicate common emails people see during site updates, or more recently with the introduction of recovery mode, fake recovery mode emails.

The goal is normally to present you with a login screen into which you will then proceed to enter your details, the bad actors then use the credentials you gave on your own site to gain access. 

While phishing is just sending lots of emails, spear phishing is sending targeted emails to a specific individual, for example if you have identified an admin of the site, so can send a Dear Bob email where you can give a little more detail to Bob such that he believes the email is genuine. 

Countering Phishing

Never click a link in an email, especially one you didn’t generate. No good workflow should have a way that you can’t do the action (even verifying emails). 

Education education education, send staff automated emails, if they click the link send them education, repeat until no one dares to click links.

Consider watermarking or signing emails generated by your WordPress install to make sure people look for those within the emails.

Make sure your SPF/DKIM records are set and your server is not coming in as junk, so people are not used to seeing emails associated with the domain in junk folder. 

Warn users if a phishing attempt is seen, and act quickly. 

2FA doesn’t prevent phishing but it makes it a lot harder to do, so make sure it’s enabled.

Empower users to manage security

By default a user can be logged in on more than one device in more than one location, which is useful as it means you can be logged in on your phone and PC at the same time. However, it also means a bad actor can be as well.

Monitoring logins, their locations and number of sessions can give some early warning. While something can be monitored by admins for many things this is about users managing accounts themselves for example:

• Consider emailing users on successful logins, with a click here if it wasn’t you style message
• Clearly show the user the last time and location they logged in, with a “flag this login”
• Maybe consider preventing logins from two distinctly different geolocations (though be aware IP might not be the best way to do this, more than once I have been on a train and the world has thought I was in Sweden, not Stevenage) 
• Provide a clear reporting mechanism.

Managing Users

User management doesn’t have to be complicated. It’s also one of the few places where actually plugins and security plugins in particular come in handy. Ultimately the simpler you make things, the easier. Give users the correct capabilities, and indeed make sure they should be there in the first place. Enforce a secure password policy and back it with education and two factor authentication. Finally, empower users to notice and report problems.

Education, Empowerment and Policy dictate user security as much as any tool, get those right and user management becomes less of a headache and our bad actors will have a hard time fooling our users.