Enforce use of application passwords for authenticated XML-RPC requests

[johnbillion]

Since WordPress 5.6, application passwords can be used to authenticate with the REST API and XML-RPC. See #42790 for the ticket and ​see here for the announcement post with all the details.

I propose that authentication via regular user passwords is disallowed for XML-RPC requests, which would leave authentication possible only via application passwords. Any custom authentication mechanisms would continue to operate as they do currently.

Reasoning

• Authentication over XML-RPC is a non-interactive workflow which means it cannot benefit from login security enhancements such as multi-factor authentication (MFA/2FA), CAPTCHA, or rate limiting. This is why the XML-RPC feature is commonly disabled.
• Enforcing application password usage for XML-RPC authentication removes the ability of bad actors to brute force user-generated passwords via this endpoint. Application passwords are 24 alphanumeric characters long and generated with a CSPRNG which results in entropy of 142 bits, well beyond the 128 bits necessary to be considered secure against brute forcing. Multi-factor authentication plugins often enforce application passwords for XML-RPC for this reason.
• Along with #21022, this will speed up XML-RPC responses as a fast HMAC will be used for hashing and checking application passwords rather than the much slower phpass or bcrypt algorithms which are needed in order to secure user-generated passwords.

Concerns

• This is a breaking change for users of XML-RPC who are using user passwords. This change needs to be communicated over a period of time before being enforced. We will need to look into what mechanisms are available to deliver this message to users of XML-RPC clients which will be affected. I don't yet know if such messaging could be delivered over the XML-RPC connection or whether it would be preferable to get in touch with known XML-RPC client developers and ask them to add messaging to their clients. Needs investigating.
• XML-RPC is considered a legacy API, however it is still in use by the WordPress mobile apps for Android and iOS. At the time of writing these apps don't yet support using the application password authorization workflow in place of inputting a user password (although they do of course support manually inputting an application password). If application passwords are to be enforced for the mobile apps then the apps will need to be updated to show relevant messaging to users in lieu of implementing an application password authorization workflow.
• Other legacy applications using XML-RPC may operate in an environment where a web browser isn't available to make use of the application password authorization workflow, or where the app isn't able to handle a response via a redirect URI from the workflow. The current application password auhthorization workflow doesn't support out-of-band responses in order to display the application password to the user, which means they'll instead need to manually create an application password from the user profile screen in the admin area. If we're going to invalidate existing user passwords for XML-RPC then end users need a way to understand what they need to do in order to switch to an application password.
• Jetpack appears to still use XML-RPC. Needs investigating.
• Application passwords are only supported over HTTPS (or when the environment type is set to local). Enforcing application passwords would mean that authenticated XML-RPC requests are no longer supported over insecure HTTP requests.

Other

• Need to consider how filters such as wp_is_application_passwords_available_for_user are used and whether it impacts this change.