WordPress 5.6 is
due out in early December 2020, and one of the new features available with it is “Application Passwords“.
This article provides some background on what this is and how you, and plugin developers, can take advantage of it. And… how Shield will handle them.
What Are Application Passwords?
They’re actually quite simple, and are exactly as they sound – they’re passwords that applications 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 provide them with your admin username and password.
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 version 5.6, support for authentication by 3rd party services was limited. The option to provide a username & password simplifies this kind of access.
Limitations of Application Passwords
For the purposes of this article and for simplicity’s sake, we’ll focus on a 2 limitations.
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 ought to.
The other limitation is in how WordPress defines “Application”.
WordPress currently exposes 2 primary APIs:
- The REST API
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 to build upon this, which we’ll get to later on.
How Do You “Get” 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 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. But if you instead do so with an Editor user, 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.
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 a user is accessed as an application or an API, this 2FA process isn’t practical.
In these cases, Shield would normally cause the login by the application to fail.
This is to be expected, as WordPress hasn’t had 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 audit trail so that you can monitor these requests.
Security Implications of Application Passwords
You may think that if WordPress is providing a “new” authentication method, surely there is more exposure to risk on your WordPress site? There isn’t.
You could say that if a user creates an application password, then there 2 passwords for the account and so that doubles the possibility of an incursion.
This isn’t how it works.
Remember, App Passwords will only be verified if the request is considered to be 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. Remember, the passwords are linked to users, and users have roles & permissions. Always grant the minimum possible privileges to achieve the goal/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, added to all of this is the fact that if you never add an App password to a user account, the system will never try to authenticate through the App Password system anyway.
Is there a need to disable the App Password system? Simply put, no. Our view on this may evolve over time as we learn more and 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 request 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 of the limitations, which was that only XML-RPC and REST API requests were considered “applications”, for this purpose.
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 mark a request so that the password will be run through the application password verification, also.
How can this be achieved? We’ve provided some sample code below in the form of a Github Gist.
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.
Official support for Application Passwords in WordPress 5.6 is very 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.