Should application password be usable for logins

[Clorith]

WordPress has, since version 5.6, bundled the ability to generate Application Passwords.

These have been usable as HTTP Basic Auth tokens for REST API requests, but that is the extent of their use within core.

In traditional use-cases, an Application Password is a specific token, used by one or more applications, to sign in and bypass the needs for other account security, such as for example two-factor authentication.

I'm not sure how SVN interacts with user accounts, but in theory would this allow for application passwords for things such as commits to plugins/themes/core?
It would also allow older integrations, like the ones relying on XMLRPC still, to continue working without additional plugins out of the box.

I'd like to open the discussion if WordPress should perhaps also allow their use for this case? It is of course possible for a plugin to implement this already, but given how different WordPress is currently treating Application Passwords from what other services do, it seems like a valuable discussion to cover :)

[JeffPaul]

This seems to line up well with @georgestephanis's ​My Two Cents on Two Factor post:

• For systems where the user cannot be prompted for a two-factor auth code (XMLRPC, etc), disallow their normal password for authentication, and force them to use a generated application password that is stored in usermeta.
• For systems where the user can be prompted for a two-factor auth code (wp-login.php) don’t permit the use of application passwords.

[georgestephanis]

Hrm. As wide ranging as the .org login system is, it'd need a lot of testing to make sure we're handling all the edge cases.

I also don't know how passwords sync with svn and such on that systems end. If it's a cli call to WP to say "hey is this username/pw valid" it would be doable, but if it's just querying the data in the users table it would need more workarounds to handle.

Also, if we were to update things to disallow normal passwords for these systems and require application passwords, it would require a lot of services and integrations to generate new passwords and may break sparsely maintained ones for a time. Which may be good or bad depending on your perspective.