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
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 a user is accessed as an application or an API, applying 2FA limitations isn’t practical or desired.
In these cases, Shield would have normally caused the login 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 audit trail 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 more exposure to risk on your WordPress site?
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 generate more sales through fear mongering. It’s a poor approach to providing security services.
You could say that if a user creates an application password, then there are 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 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, 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.
Q: Is there a need to disable the App Password system?
Simply put, no.
Our view on this may evolve over time 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.