WordPress 5.6, released in December 2020, brings us a shiney new feature: “Application Passwords“.

This guide provides some background on what Application Passwords are and how you, and plugin developers, can take advantage of the feature, and whether there are any security concerns with them (there isn’t).

We’ll also cover how Shield Security has been adapted to handle them.

What Are Application Passwords?

They’re actually quite simple, and are exactly as they sound – they’re passwords for your WordPress site that apps can use, not humans. They allow you to authenticate with a service, without using your “human” login credentials.

You could also think of them as “Passwords for APIs”.

Some automation services, such as Zapier, need to authenticate with your WordPress site. Until WP 5.6, there’s been no built-in way to allow this. Often, to achieve this integration, you need to use your admin username and password.

Q: But who wants to give any service their admin username and password?
Hint: it’s the opposite of “everybody” 🙂

Another huge use-case of application passwords is with the WordPress REST API. Before WordPress 5.6, support for authentication by 3rd party services was quite limited. The option to provide a username & password simplifies this type of API access.

Limitations of WordPress Application Passwords

For the purposes of this article and for simplicity’s sake, we’ll focus on 2 limitations of Application Passwords.

In the case of WordPress, the big limitation is that you can’t login into the admin area of your WordPress site using an application password.

But this is a “feature”, not really a limitation. 🙂

This is because you aren’t an “application”. So trying to login with an app password will fail. As it should.

The other limitation is in how WordPress defines “Application”.

WordPress currently exposes 2 primary APIs in its native code:

  • The REST API
  • XML-RPC

By default, WordPress 5.6 doesn’t consider anything outside of these 2 APIs to be an “Application”, insofar as app passwords are concerned.

Luckily, they’ve provided a way for developers to build upon this, which we’ll get to later on.

How Do You “Create” An Application Password?

Application Passwords are linked directly to individual WordPress users.

By linking to users, it also implies the precise access permissions granted to an application when they’re given access to your WordPress site.

For example, if you create an app password on your administrator account, the application will have full admin rights to your site. But if you use an Editor user instead, you’ll limit what an application may be able to do.

You’ll see a new section in the WP user profile page for managing these passwords. Simply click to create a password and use this in-place of your login password when supplying credentials to service providers.

How Does ShieldPRO Handle Application Passwords?

ShieldPRO hooks into user authentication in a number of ways when protecting user accounts from malicious access or activity.

One of these is when a user logs in and their account has 2-Factor Authentication (2FA) requirements.

Normally, a human will login, then complete the 2FA process by providing a code sent by email, or Google Authenticator. But when an account is authenticated as an application or an API, applying 2FA limitations isn’t desired.

In these cases, Shield would have normally caused authentication by the application to fail.

This is to be expected, as WordPress didn’t have native support for API passwords until version 5.6.

From version 10.1.4 onward, ShieldPRO wont apply 2FA checks for any Application Passwords. It’ll also capture logins using application passwords and add these to the activity log so that you can monitor these requests separately from normal user logins.

Security Implications of Application Passwords

You may think that if WordPress is providing a “new” authentication method, surely there is greater risk to your WordPress site?

There isn’t. Plain and simple.

You may hear that Application Passwords are a security risk in different forums, or even from some of our competitors. We don’t agree.

The only advantage of saying they’re a security risk and then offering the feature to “block them” is that it generates sales. Fear mongering is a powerful sales technique, but it’s manipulative so we don’t do it.

You could say that if a user creates an application password, then there are 2 passwords for the account, doubling the risk that a user account will be compromised.

This isn’t how it works.

Remember, App Passwords will only be verified if WordPress sees the request as coming from an “application”. You simply can’t log into your normal admin account using an App Password. (Someone may point out that you can do so, but only if you mess about with WordPress filters and unwittingly allow it).

As we mentioned before, if you’re going to grant an application access to your site, ensure that you assign the password to a user with minimal privileges – this is the Principle of Least Privilege. Remember, the passwords are linked to user account, and have that user’s have roles & permissions. Always grant the minimum possible privileges to achieve the goals of the integration.

But what about “brute force attacking your REST API”? This is the same as it’s always been if you’re using Shield – any attacker that tries this will meet Shield’s defenses and eventually be blocked from the site entirely.

Furthermore, if you never add an App password to a user account, the system will never try to authenticate through the App Password system.

Q: Is there a need to disable the App Password system?
No.

Our view on this may change over time and as the app password system evolves, but for now, disabling the system appears to be unnecessary.

Exploring The Real World Challenges Of Application Passwords

Adapting Shield to handle WordPress’ new Application Passwords started after a discussion with a client about how Shield was blocking Zapier requests.

As we discussed earlier, blocking these requests was to be expected.

With ShieldPRO 10.1.4, we have full support for application passwords so these requests wont be interrupted. But, it’ll still depends on a few things.

If you’ll remember earlier we talked about some app password limitations – that only XML-RPC and REST API requests were considered “applications”.

What if your 3rd party plugin uses neither of these channels to work with the site?

There’s bad news and there’s good news.

First the bad news: it’s not going to work.

Application passwords are only processed if the service is using one of these 2 channels. The service provider will need to update their implementation to take account of this, before any of this will work.

Now the good news: WordPress offers the ability to flag a request as an “application request” on-the-fly, even though it’s neither XML-RPC nor REST.

Using a WP filter you can signal to WordPress that it should also consider such requests as “applications” and verify application passwords, also.

How can this be achieved? We’ve provided some sample code below in the form of a Github Gist.

<?php
/**
* WordPress (5.6+) allows the use of Application Passwords when authenticating logins.
* However, only certain requests are considered to be requests from an "Application". Officially, these are
* XML-RPC and REST API requests.
*
* However, you may customize this to ensure that authenticated requests from your service
* (if they don't use XML-PRC/RESTAPI) are put through the appropriate authentication process.
*
* To achieve this, you make use of the filter: application_password_is_api_request
*/
add_filter( 'application_password_is_api_request', function ( $isApiRequest ) {
// Insert your logic here.
// E.g. the originating IP address is from your application server
if ( $_SERVER[ 'REMOTE_ADDR' ] === 'is.my.ip.address') {
$isApiRequest = true;
}
// Always return $isApiRequest
return (bool)$isApiRequest;
} );
view raw functions.php hosted with ❤ by GitHub

If you’re talking with a service provider, like Zapier, and they don’t use XML-RPC or the REST API, you can point them to this code as a simple example to help them integrate Application Passwords into their service plugins.

Finishing Up…

Official support for Application Passwords in WordPress 5.6 is welcome, indeed. There are plenty of scenarios where this will prove very useful and we hope that the uptake will be strong across service providers.

As always with anything new, there is a learning curve and while we believe we’ve capture the essence of Applications Passwords within Shield, there may be areas we’ve missed. Drop us a line if you see any issues or have any feedback on areas to improve.