Moving toward enforcing use of application passwords for authenticated XML-RPC requests

[johnbillion]

This affects both the iOS and Android apps.

I am investigating the viability of enforcing the use of application passwords for authenticated XML-RPC requests in WordPress core. The benefit this has is that it greatly reduces the ability to brute force user passwords via the XML-RPC endpoint which is typically difficult or impossible to protect with rate limiting or additional authentication methods unlike wp-login.php.

Core ticket: https://core.trac.wordpress.org/ticket/62789

One of the prerequisites of this change is that the mobile apps provide a good UX for users who are currently using a user password rather than an application password and need to switch over. I anticipate that some form of messaging will be added to a WordPress release prior to actually implementing the switch, so that users are given time to switch over.

There are two ways for a user to use an application password:

1. Manually generating one from their profile screen and copy-pasting the value into a password input along with their username.
2. Using the application password authorisation workflow, which directs the user to their site and subsequently sends the username and application password back to the requesting application.

My understanding is that neither the iOS or Android apps support the authorisation workflow yet, is that correct? I see some work has been done in #23473 and #23726 but I'm not sure of the status of it.

• Is there a way we can use messaging in the XML-RPC response to alert affected users to the change? I've yet to look into this at all.
• Is there a way we could create a user application password over XML-RPC via the app and overwrite the stored user password? This has the potential to make the enforcement entirely invisible to the end user. Adding new custom XML-RPC methods should be a possibility.
• Any ideas about improvements that could be made to the application password authorisation workflow UI and UX are welcome. We could even think about going as far as bundling dedicated support for the WordPress apps and other common XML-RPC clients such as MarsEdit in order to get rid of the suboptimal display of the redirect URL.
• Does this affect the Jetpack connection option? I've also not yet looked into this.

Let's discuss what work would need to be done in the apps and in WordPress core to support a good UX or an invisible UX for users.

[dangermattic]

Thanks for reporting! 👍

[danielpunkass]

Thanks for starting the discussion. I'm the developer of MarsEdit so I have a long-term perspective on being a client of the XML-RPC API that is probably comparable to the experiences of the Android and iOS app teams.

To quickly respond to some of your proposals:

1. To alert affected users of the change. I suspect the most reliable means of doing this would be by failing authentication with an error that does not look like a typical authentication failure. I'm not sure if the mobile apps behave the same way, but when MarsEdit sees an authentication error it assumes the user entered the wrong password, so just prompts them again. I wouldn't be surprised if responses to authentication errors specifically are typically not too nuanced, and so you wouldn't be able to reliably pass along an error message.

On the other hand, if you were to return a non-authentication error with an error message it might be the case that existing apps would already naturally present this information to users. This would be something to investigate: is there an error that is returned that reliably causes most affected clients to display a reasonable error message?

Assuming there is such an error message, one possibility would be to phase in the requirement by returning this error message just once, effectively notifying the user of a pending requirement change, and then commence handling XML-RPC requests as usual. I imagine this would require storing a flag somewhere on a per-user basis that such an XML-RPC notification had been delivered once already.

2. I like the idea of "upgrading" a password based credential over the API itself. If I recall correctly the Tumblr API did something along these lines years ago when it migrated from passwords to "xAuth" (they're sort of Twitter-style compromise for obtaining OAuth-like tokens from a password). This mechanism could also be useful for clients that are migrating from XML-RPC to REST, if they could use it to seamlessly transfer the user's credentials.

3. I will think about the possibility of authentication workflow improvements that might be made. Truly, anything that streamlines the process of taking a user from "I just downloaded this app" to "I'm editing my blog" will benefit the UX for the official apps and any 3rd party apps like mine.

[jkmassel]

Howdy folks – we're actively working on migrating users to Application Passwords (and the REST API – Application Passwords are a means to that end).

To answer some questions:

Is there a way we can use messaging in the XML-RPC response to alert affected users to the change? I've yet to look into this at all.

Not with the current APIs, but we plan to gently start migrating folks to Application Passwords over time – first with "here's a new feature you can use if you adopt Application Passwords", then eventually with "this feature will no longer work until you adopt Application Passwords".

Is there a way we could create a user application password over XML-RPC via the app and overwrite the stored user password? This has the potential to make the enforcement entirely invisible to the end user. Adding new custom XML-RPC methods should be a possibility.

That would be wonderful, but no – we're planning to put UI in place to notify the user that they need to sign in again. This will show them the Application Passwords flow. At that point, they'll be migrated and shouldn't have to do anything else.

Any ideas about improvements that could be made to the application password authorisation workflow UI and UX are welcome.

There are still some things we can't access using Application Passwords – for instance, there's no mechanism for trading an Application Password for a cookie, and that's needed to show post previews (a mechanism to show post previews with just an application password would be interesting, too). We also still need cookies for some hacks that involve scraping wp-admin pages.

We could even think about going as far as bundling dedicated support for the WordPress apps and other common XML-RPC clients such as MarsEdit in order to get rid of the suboptimal display of the redirect URL.

This would be very cool if it were possible, but I'm not certain that'd be adopted into Core.

Does this affect the Jetpack connection option? I've also not yet looked into this.

It doesn't affect the Jetpack connection for the apps – it may affect the Jetpack product but I think they could figure that out without too much trouble.

---

Happy to engage with this process – full REST API support is one of our top priorities, and authentication is obviously an essential part of that. If you're interested in what we're up to, feel free to checkout https://github.com/automattic/wordpress-rs :)