The WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
Found a bugbugA bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.?Create a ticket in the bug tracker.
The primary focus of the scrub will be reviewing PRs in the milestone to see which are ready (or close enough) to be wrapped up and merged versus punted to a future release. We will also review issues in the milestone that don’t have a linked PR to see if they’re urgent enough to work on a PR versus punted to a future release. The most pressing issue is two-factor#423 given its already impacting, so particular focus on that and its associated PR#427 will likely be where we begin the conversation.
The most helpful thing would for folks present during the scrub, or also helping asynchronously, will be testing those PRs in the milestone to ensure that they (1) resolve the root issue and (2) have no merge conflicts. Leaving a comment with your results on PRs will help dramatically.
There’s no immediate timeline for the 0.8.0 release though once we get through the bug scrub George and I will have a better sense of what work remains in getting 0.8.0 released. The sooner we can get a release out that includes a resolution for two-factor#423 the better, so thanks to all for helping!
WordPress 5.6 will finally see the introduction of a new system for making authenticated requests to various WordPress APIs — Application Passwords.
The existing cookie-based authentication system is not being removed, and any custom authentication solutions provided by plugins should continue to operate normally.
For any sites using the Application Passwords feature plugin, it is recommended to deactivate the pluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party after upgrading to WordPress 5.6. However, sites won’t experience any errors if the plugin remains active. The current plan is to use the plugin for future prototyping.
Application passwords can be used with or without the spaces — if included, spaces will just be stripped out before the password is hashed and verified.
WordPress will be storing a user’s application passwords as an array in user metaMetaMeta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress., similar to how interactive login sessions (via WP_Session_Tokens) are stored already.
From the Edit User page, you can generate new, and view or revoke existing application passwords. The form and the list table are both fully extensibleExtensibleThis is the ability to add additional functionality to the code. Plugins extend the WordPress core software. to allow for overloading to store additional data (more on this later, in “Authentication Scoping”).
Once a given password has been used, it will keep track of where and when it has been used – the “Last Used” column is accurate to within 24 hours (so that WordPress isn’t writing to the database on every usage — only if it’s a new day). This can be incredibly useful for identifying passwords that are no longer in use, so that they can be safely revoked.
To ensure that application password functionality is available, fire off a request to the REST APIREST APIThe REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. root URLURLA specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org, and look at the authentication key in the response data. If this key is empty, then application passwords are not available (perhaps because the request is not over https:// or it has been intentionally disabled).
If, however, response.authentication is an object with a key of application-passwords it will offer a URL to send a user to complete the authentication flow. (You could just guess at the URL, but this gives us more of the relevant information in one go, as well as confirming that application passwords are available and enabled.)
The response.authentication['application-passwords'].endpoints.authorization url will likely look something like this:
Instead of just sending the user there to generate an application password, it would then be up to the user to reliably re-enter it into your application. So instead, some additional GET parameters are accepted along with the request:
app_name (required) – The human readable identifier for your app. This will be the name of the generated application password, so structure it like … “WordPress Mobile App on iPhone 12” for uniqueness between multiple versions. Whatever name you suggest can be edited by the user if they choose before the application is created. While you can choose to not pre-populate it for the user, it is required to create a password, so they will then be forced to create their own, and could select a non-intuitive option.
app_id (recommended) – a UUID formatted identifier. The app_id allows for identifying instances of your application, it has no special meaning in and of itself. As a developer, you can use the app_id to locate all Application Passwords created for your application. In the event of a data breach, your app_id could be distributed to void credentials generated with it, or if a site wants to allow only a given app_id or set of app_ids to register, this would enable that. However, it is strictly on the honor system — there is nothing to stop applications from generating new uuids with every authorization.
success_url (recommended) – The URL that you’d like the user to be sent to if they approve the connection. Three GET variables will be appended when they are passed back (site_url, user_login, and password); these credentials can then be used for APIAPIAn API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. calls. If the success_url variable is omitted, a password will be generated and displayed to the user instead, to manually enter into their application.
reject_url (optional) – If included, the user will get sent there if they reject the connection. If omitted, the user will be sent to the success_url, with ?success=false appended to the end. If the success_url is omitted, the user just will be sent to their WordPress dashboard.
As the parameters are all passed in via GET variables, if the user needs to log in first, they will all be preserved through the redirect parameter, so the user can then continue with authorization.
It is also worth noting that the success_url and redirect_url parameters will generate an error if they use a http:// rather than https:// protocol — however other application protocols are acceptable! So if you have a myapp:// link that opens your Android, iOS / MacOS, or Windows — those will work!
The application passwords authentication scheme can also be applied to future APIs for WordPress as they become available. For example, if GraphQL or other systems are enabled in WordPress, application passwords will provide them with a solid, established authentication infrastructure to build off of out of the box.
You can’t. 😅 The point of application passwords are that they are to be used programmatically for applications, and not by humans for interactive sessions.
By default, Application Passwords is available to all users on sites served over SSLSSLSecure Sockets Layer. Provides a secure means of sending data over the internet. Used for authenticated and private actions./HTTPSHTTPSHTTPS is an acronym for Hyper Text Transfer Protocol Secure. HTTPS is the secure version of HTTP, the protocol over which data is sent between your browser and the website that you are connected to. The 'S' at the end of HTTPS stands for 'Secure'. It means all communications between your browser and the website are encrypted. This is especially helpful for protecting sensitive data like banking information.. This can be customized using the wp_is_application_passwords_available and wp_is_application_passwords_available_for_user filters.
For example, to completely disable Application Passwords add the following code snippet to your site.
Without SSL, it is possible for the Application Password to be seen by an attacker on your networknetwork(versus site, blog) or the network between your site and the authorized application. If you are ok with this risk, you can force availability with the following code snippet.
In future versions, the expectation is to include the ability to scope a given application password to limit its access. The intention is to work on building this in plugin-land until it’s ready for a core proposal.
What might password scoping look like? Here’s some methods being considered:
In a multisitemultisiteUsed to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site environment, either restrict the credentials to a subset of the user’s blogs, or restrict it to only operate in a normal “blogblog(versus network, site)adminadmin(and super admin)” context, and not a “network admin” context.
Restrict functionality to only manage content — posts, pages, comments, custom post types — and disallow infrastructure management functionality like managing plugins, themes, and users.
Restrict the role that credentials can allow an application to operate as. For example, an Editor may restrict a set of credentials to only operate as though they had Author or Contributor permissions.
However this is done, implementing additional functionality to enforce the principle of least privilege on an application-by-application basis is a worthwhile expansion on the included functionality.
Right now, a user’s application passwords can be managed by any user who has permission to edit_user them. The ability to customize this behavior using a new set of more fine-grained capabilities is currently planned for 5.7.
Eventually Two-Factor Authentication?
Another useful bit of application passwords is that it will removes an obstacle for the inclusion of multi-factor authentication on interactive logins.
Previously, if you enabled an interactive step — whether captcha or second factor validation — on login pages, you would be in a bind with other non-interactive authentications, for example the legacy XML-RPC system. After all, if a bad actor can just brute force or use social engineering to discern the user’s password, it would be trivially usable via XML-RPC, where there is no ability to include an interactive prompt, and that functionality would need to be disabled entirely.
With that use case now being provided for via application passwords, there is additional flexibility for the normal browser-based wp-login.php system to evolve.
Core TicketticketCreated for both bug reports and feature development on the bug tracker.: #42790
Feature Plugin. Further development of App Passwords will be prototyped in this repo.
For bugbugA bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. reports or enhancements, open a Trac ticket in the new App Passwords component with the rest-api focus.
Problem statement: no way to authenticate third-party access to REST APIREST APIThe REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/.
Ever since the REST API infrastructure merged via #33982 and shipped in WordPress 4.4 in December 2015, it’s been gaining momentum and been used in more and more places—throughout WordPress’s adminadmin(and super admin), via plugins and themes, and enabled deep, robust interactions powering new functionality such as the GutenbergGutenbergThe Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/blockBlockBlock is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editor.
However, the functionality has been limited in that the only way to make authenticated requests to the APIAPIAn API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. in coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. has been through Cookie & Nonce-based authentication—there is no good way for third-party applications to communicate with WordPress in an authenticated fashion, apart from the legacy XML-RPC API.
This has resulted in frustration for our Mobile teams especially as they’re working to integrate Gutenberg support, which relies on the REST API. After some time having to store username/password to spoof a cookie and interactive session to scrape a nonce from the wp-admin DOM, and then to use an endpoint to get it instead via . All of which is a tremendously messy and awkward usage that completely falls apart if someone uses a variant of a two-factor authentication system.
Spoofing an interactive session just to make API requests is bad form and needlessly complex.
There have been many systems considered, including everything from multiple incarnations of OAuth, JWT, and even some solutions that are combinations of the two. Some called for a centralized app repository, some had open registration, but all were complex and none of them could build sufficient traction to come to fruition.
Given a login and an application password, making an API request is as simple as
curl --user "USERNAME:APPLICATION_PASSWORD" -X POST -d "title=New Title" https://my.wordpress.site/wp-json/wp/v2/posts/POST_ID
It uses the standard HTTPHTTPHTTP is an acronym for Hyper Text Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands. authorization headers. Everything supports this trivially.
Benefit: Ease of Revoking Credentials
Application Passwords makes it easy to revoke any individual application password, or wholesale void all of a user’s application passwords. Application Passwords also lists the date a password was last used and the IP it was used from to help track down inactive credentials or bad actors using them from unexpected locations.
Benefit: Ease of Requesting API Credentials
While it is possible for a user to go to their user profile page and generate a new application password, for example if they are creating a command line tool for themselves, the ideal workflow looks something like this:
To request a password for your application, redirect users to:
and use the following GET request parameters to specify:
app_name (required) – The human readable identifier for your app. This will be the name of the generated application password, so structure it like … “WordPress Mobile App on iPhone 12” for uniqueness between multiple versions. If omitted, the user will be required to provide an application name.
success_url (recommended) – The URL that you’d like the user to be sent to if they approve the connection. Two GET variables will be appended when they are passed back (user_login and password); these credentials can then be used for API calls. If the success_url variable is omitted, a password will be generated and displayed to the user, to manually enter into your application.
reject_url (optional) – If included, the user will get sent there if they reject the connection. If omitted, the user will be sent to the success_url, with ?success=false appended to the end. If the success_url is omitted, the user will be sent to their WordPress dashboard.
If the user is logged out, they’ll be redirected to the WordPress Login page. After logging in, they’ll be immediately redirected back to the Authorize Application screen.
In discussions with @timothyblynjacobs we’re unsure about whether to add a state parameter (which is just stored and passed back to the application to prevent CSRF attacks). Realistically apps could just include it on their own in the success_url or a site_url parameter (which could remind the application what site the returned credentials are for). Requiring apps to pass a state parameter could encourage best practices, but we wouldn’t be able to enforce that they validate its contents.
It’s also worth noting that the success_url and reject_url are both explicitly designed that apps can pass in custom protocols for the return URLs. That is, they could set them to be wordpress://authentication so that the user’s phone automatically redirects them back from their web browser, directly into the application with the credentials appended to the query. You may have seen this previously with other applications where you “Login with Facebook” in your browser and then Facebook sends you directly back into your app. Or with how your web browser can open Zoom directly on your laptop, pre-populating the room ID and password.
Benefit: Login Security
Unlike pure basic auth that requires entering in credentials directly into the application, Application Passwords allows for an interactive authentication flow. This means that login security features like Two Factor or reCAPTCHA can continue to protect user accounts.
One of the reasons XML-RPC is so often recommended to be disabled is that it allows brute forcing user’s passwords since those additional security protections can’t be implemented. A risk of implementing pure basic auth is that sites will be forced to disable it because it can’t be interactive.
Proposed solution: merge Application Passwords to core
Props to @timothyblynjacobs for help on the content of this post, @jeffpaul for help on the structure of this post, and the many many people who have contributed to the analysis behind this proposal and to Application Passwords.
@audrasjb shared an update on WP Auto-updates Feature PluginFeature PluginA plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins.: it was moved from his personal GitHubGitHubGitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ account to WordPress/wp-autoupdates which is the new official GitHub repository of this project. The #core-auto-updates team will try to ship version 0.4 before WP 5.4 is released. This new version aims to handle auto-updates for themes.
@afragen asked for a review of some Trac tickets which are all associated with Theme compatibility checks and will likely have interaction with the auto-updates feature. The idea is to ship them early in WordPress 5.5.
@whyisjake pointed out that he really like the work that is going on in #core-auto-updatesSlackSlackSlack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel and think that trying to land in the next few releases would be excellent. Related, He’d love to see #core-passwords (two-factors authentification – 2FA) land in coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. too. In his opinion, the pluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party is so mature at this point that having it left out almost seems like an omission. @whyisjake is going to work on a merge proposal.
@clorith raised that it would be necessary to make sure that the 2FA proposal also highlights the concerns with how to address users locking them selves out (which was the major holdback previously).
TrunktrunkA directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. has been branched to 5.5 on the beginning of March. That means 5.5 is officially in Alpha.
@francina announced that work for 5.6 –which is going to be an all-women release– has kicked off with an initial round of messages going out to the women that expressed interest. @angelasjin@francina and Chloé Bringmann are contacting them to hear if they are still interested, what skills they have and what expectations.
@francina shared a proposal to change the Components Check-in. This is always done towards the end of the chat and feels rushed. There is never really time to dig into the topics they might bring up. Francesca shared two ideas:
Schedule a weekly post where they can leave their status update, like the one for Community deputies.
Adopt a Slack Bot that once a week will ask the maintainers for a status update: maybe in a new component-maintainers Slack channel. Core is getting very busy with TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. and Travis bots, and RSS.
@johnbillion added that trying a weekly post could be a good idea. Maybe every Tuesday so it’s ready for the dev chat on Wednesdays in case anything comes up.
@francina proposed to talk to #meta to set this up and test drive it for 8 weeks.
@isabel_brison proposed to create a set of guidelines for Internet Explorer support. The CSSCSSCascading Style Sheets. team kind of decided on starting to deprecate it, and “graceful degradation” seems a good way to go forward, meaning Core can use unsupported technology to make non-essential enhancements. Isabel wants to agree on what’s “essential” here, and created a Trac ticketticketCreated for both bug reports and feature development on the bug tracker. to start the discussion: #49696
@paaljoachim suggested to puntpuntContributors sometimes use the verb "punt" when talking about a ticket. This means it is being pushed out to a future release. This typically occurs for lower priority tickets near the end of the release cycle that don't "make the cut." In this is colloquial usage of the word, it means to delay or equivocate. (It also describes a play in American football where a team essentially passes up on an opportunity, hoping to put themselves in a better position later to try again.) default full screen mode to 5.5 as there is a pull request on Gutenberg project GitHub repository to provide an alternative approach.
@audrasjb pointed out that the proposal in this pull request would be a way better than the current implementation.
@whyisjake added that this is not a realistic change for WP 5.4, it’s a proof of concept, and not a fully tested feature.
@joyously stated it’s hard to contribute when concerns are ignored. @chanthaboune answered she can understand how they can feel ignored. A lot of that research gets done solo, and it’s often hard to remember to recap your own research. For full site editing to be a reality by the end of the year, the work can start bringing incremental changes. This change is feeling very jarring, but there is more worry about not have any mid-point between here and Full Site Editing.
@peterwilsoncc, @clorith and @audrasjb agreed that since RC4 was released, it’s not realistic to revert this change. The discussion can continue in a post-mortem post on Make/Core.
WordPress 5.4 BetaBetaA pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1 was released on Tuesday 11 as expected 🎉
The Docs squad has published the first two dev notesdev noteEach important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase.:
The idea is to publish dev notes as soon as possible during the beta cycle and then publish the Field GuideField guideThe field guide is a type of blogpost published on Make/Core during the release candidate phase of the WordPress release cycle. The field guide generally lists all the dev notes published during the beta cycle. This guide is linked in the about page of the corresponding version of WordPress, in the release post and in the HelpHub version page. before Release Candidaterelease candidateOne of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta)..
@audrasjb offered a quick update on Automatic Updates for Plugins and Themes. Because there is still work needed, along with extensive testing, decision is to start by managing autoupdates in a feature pluginFeature PluginA plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. and then merge into CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. for 5.5.
Work on this feature plugin will start in the coming weeks.
Recently, this component returned to the Components page as per this Meta ticket, and it turned out that Administration still has a lot of tickets. The long term idea is to triagetriageThe act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. all the tickets that are there and, as part of that process, move those tickets to other components with the administration focus.
@whyisjake shared that he attended the CMS Security Summit last week, and Two-Factor Authentication was a major takeaway from the event, as was bringing automatic updates into Core.
@xkon added that #49200 needs input, so the team asks for yours. If you have any interest at all in cryptographic signature for plugins and themes, please follow the discussion on the dedicated Slack channel, core-signatures, and consider helping out.
On Thursday of last week, we had an Authentication chat in #core-passwords — truth be told, the discussion spilled over into Friday and a bit on Saturday as well. I delayed posting this summary a bit to make sure there wasn’t anything else about to be said that I’d miss.
Spoiler alert: we didn’t decide anything conclusively, it was more brainstorming and voicing possibilities.
Also worth noting is that we place equal weight on the user experience of the authentication system as we do on the security when evaluating it for coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress.. That isn’t to say that we value the security any less, but rather that we also view the UXUXUser experience as critical to nail down as well, and is likely easier to suss out problems earlier on in casual conversation than evaluating the eccentricities of crypto. So if some of the discussion tended more towards UX considerations than Security considerations, be aware that both are critical, we were just tending to evaluate the UX first, as it’s an easy litmus test for whether a particular method is worth pursuing, and more easily understood by more people than the intricacies of replay attacks and the sort.
There were two major areas of discourse that were addressed: Authentication Scheme, and Authentication Scope.
The scheme would be one of several possibilities, such as OAuth 1.0a, OAuth 2, Application Passwords sent as Basic Authentication, or some other either ad-hoc or previously unconsidered system.
There are assorted concerns with various systems:
HTTPSHTTPSHTTPS is an acronym for Hyper Text Transfer Protocol Secure. HTTPS is the secure version of HTTP, the protocol over which data is sent between your browser and the website that you are connected to. The 'S' at the end of HTTPS stands for 'Secure'. It means all communications between your browser and the website are encrypted. This is especially helpful for protecting sensitive data like banking information. — WordPress cannot guarantee that the site will be hosted on a HTTPS infastructure, and as such, any APIAPIAn API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. tokens passed along with the request could potentially be sniffed in transit. However, if the site doesn’t have HTTPS available, the same thing happens on every page you view already with your authentication cookies. The major difference being that cookies become invalidated on logout or expiration, so cookie thieves have a smaller window to exploit the stolen authentication than tokens that are valid until revoked.
OAuth Application Registration — The user experience flow for OAuth can be particularly tricky. Imagine it: You’ve just installed an app on your phone, and you want to link it to your user account on your WordPress site. Your steps are as follows: Log in to your WordPress site, Create an AppID for the phone app, give the phone app it’s Secret tokens. Now from the Phone app, you click a button to go back to your site and approve the link to your user in the application and exchange user access tokens. That is a /lot/ of back and forth-ing. It could be simplified somewhat if there was some sort of central repository for all WordPress sites that apps could register at, and then .org sites could dynamically pull down public keys for applications that they can use to verify the secrets in the apps, but that then becomes a significant amount of overhead for the construction and maintenance of the application ‘clearing house’ and it’s been clarified that it is not something that WordPress.orgWordPress.orgThe community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ (the website) is up to build or host. Long story short: this UX flow is so confusing that it really feels much more like pluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party territory at its current iteration.
Probably some other points I’m missing, but those felt like the major two.
The second issue at hand is one of Authentication Scope. That is, when an application authenticates, what functionality is it permitted to do?
This is significantly different from user capabilities. We had discussed an extra field when auth’ing applications where you could ‘downgrade’ your user role for that application’s API requests (that is, if you’re an Administrator, you could only give an application Author capabilties), but that doesn’t really solve the issue — as every user role has the ability to — for example — update their password or email address. And if an application can do that, then that’s the ballgame, and they can log in to wp-adminadmin(and super admin) as you and do whatever they like.
We also talked about perhaps just disallowing certain functionality from ever being used as a part of the REST APIREST APIThe REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/.. However, with the rise of third-party site management applications, such as Calypso, or if other programs like ManageWP or InfiniteWP or whatever the other half dozen ones are wants to truly manage your site, they’ll need access to that functionality. After all, what’s the point of aiming at eventually achieving REST API parity with the wp-admin experience if it can’t be used anywhere outside of wp-admin?
The solution we seemed to be leaning towards is a ‘two-tiered’ scope system. That is, provide a default ‘content’ tier — akin to the functionality of the legacy XML-RPC API — that can support writing and updating posts, taxonomies, comments and the like (and any custom endpoints that are explicitly opted in to the limited tier), and a second ‘full control’ tier that allows access to everything — plugins, themes, users, what have you. The second tier would be suited for full control applications like Calypso or remote management tools, whereas the first more limited tier would be more than adequate for the functionality in the legacy WordPress mobile apps, or blogging applications like Desk or Microsoft Word integration. It’s simple enough for users to understand, and technologically could be passed in via the `$args` array to `register_rest_route()` whether an endpoint should be available or not.
Still with us? Thanks for slogging through a somewhat lengthy summary, we’d love to hear your thoughts below on anything you think we missed or didn’t consider sufficiently in depth.
If anyone would like to read the full discussion, it starts here in the Slack logs: https://wordpress.slack.com/archives/core-passwords/p1455832859000040
The Two-Factor PluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party is currently on a brief hiatus, while we work on splitting off it’s Application Passwords feature into a smaller, solo feature pluginFeature PluginA plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins..
Application Passwords was initially a sub-feature of Two-Factor Authentication, but due to the fact that we had very little confidence in Two-Factor being ready for the 4.5 cycle, we spun off a nearly-complete sub-feature that may mesh very well with the existing REST APIREST APIThe REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/..
Application Passwords lets each user choose to generate “Application Passwords” — randomly generated 16-character alphanumeric codes, that are only displayed to the user once, upon creation. These passwords can be revoked either individually or all at once, and track usage, so in the adminadmin(and super admin)UIUIUser interface you can view the most recent IP and Date that the password in question was used.
The passwords are only valid for non-interactive prompts. That is, for use with our XML-RPC and REST APIs. They can not be used on `wp-login.php` or to access the admin panel. The idea is that each application you connect to your WordPress account — a mobile app, if this then that, Microsoft Word, or some sort of local blogging software, they all have their own password that can be revoked if the device is lost or no longer in usage, all without dispensing full access to your account.
For folks building a quick one-off script that needs to tie into WordPress, this is far simpler than using the obscure oAuth version that CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. has to use because we can’t guarantee HTTPSHTTPSHTTPS is an acronym for Hyper Text Transfer Protocol Secure. HTTPS is the secure version of HTTP, the protocol over which data is sent between your browser and the website that you are connected to. The 'S' at the end of HTTPS stands for 'Secure'. It means all communications between your browser and the website are encrypted. This is especially helpful for protecting sensitive data like banking information., and far more secure than the existing “use your account password for api calls” standalone plugin, that many folks would likely choose to default to otherwise.
Code reviews, issues, and pull requests are very welcome.
Following some critical feedback and discussions both at the Community Summit and at WordCampWordCampWordCamps are casual, locally-organized conferences covering everything related to WordPress. They're one of the places where the WordPress community comes together to teach one another what they’ve learned throughout the year and share the joy. Learn more. US, we’re adjusting our focus. Technical feasibility is turning out to be far less of a concern than ensuring we don’t create an undue support burden by users getting locked out and providing a way back in.
Previously, we had been anticipating the primary way to override a loss of their second factor would be either adding a constant or modifying the database records (either directly or via a shell tool such as WP-CLIWP-CLIWP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/https://make.wordpress.org/cli/). However, we have had a number of concerns from assorted interested parties, and the fact of the matter is that it is feeling like too high of a barrier for many WordPress users. As @macmanx (new Forums Team RepTeam RepA Team Rep is a person who represents the Make WordPress team to the rest of the project, make sure issues are raised and addressed as needed, and coordinates cross-team efforts.) summarized in our chat yesterday,
I’ll say it this way: We want users to be able to secure their sites with 2FA, not sit back and watch outdated abandoned sites pile up because they locked themselves out and simply give up when when we mention FTPFTPFTP is an acronym for File Transfer Protocol which is a way of moving computer files from one computer to another via the Internet. You can use software, known as a FTP client, to upload files to a server for a WordPress website. https://codex.wordpress.org/FTP_Clients., Database, or SSHSSHSecure SHell - a protocol for securely connecting to a remote system in addition to or in place of a password..
So, there are several things that have been brought up:
Require a constant in `wp-config.php` to enable 2FA
The idea being that, by adding a constant to wp-config, the user has demonstrated that they know how to use FTP and edit files on their server manually, so if all goes to heck, they have the ability and knowledge to take the constant back out, so they can get back into their site adminadmin(and super admin).
I feel that this is a bad idea, because it violates many of the WordPress Core Philosophies. It wouldn’t work out of the box, and we’re no longer designing for the majority. It results in us adding not only an option, but an option that’s hard to set.
If we have to hide it behind a constant, I feel that it shouldn’t even be in CoreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress., and would be better left as a pluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party.
(yes, I know MultisitemultisiteUsed to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site runs this way, but there are other reasons that was merged into core)
Require multiple providers being enabled
The idea here being that if the user has two, there is less likelihood of getting locked out as they’d have a backup. However, for myself, I can’t tell you how many times I’ve downloaded backup codes and promptly lost them. Or how many times my phone has been destroyed (washing machines and phones shouldn’t be friends). There’s still a lot of opportunity for things to go wrong, especially on the scale of powering a quarter of the web. Edge cases become commonplace. 🙁
Send Text Messages
No can do, this would require a third-party server to send them through, and that’s plugin territory.
Leave Emailed Codes as an always-available fallback
This, I feel is our best option.
There are some concerns regarding the large percentage of WordPress sites that are on servers that can’t send email (as high as 25% by some guesstimates I’ve heard floated), so we’d need to send a code and make sure it gets received before turning on the actual two-factor login prompt.
While it doesn’t provide the best security (if someone breaks into your email address, they could both reset your password and get the incoming authentication code), it is 1) no worse than the status quo, 2) not our responsibility to keep secure, and 3) if they’ve broken into your email, you probably have bigger concerns.
We can certainly include a filterFilterFilters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. for methods to disable / add from plugins, and so if someone wants to disable email manually, they totes can. By explicitly disabling the Core security feature, they’re then demonstrating that they know enough to fix it if it goes wrong.
In the end, my feelings were largely best summed up by @michael-arestad, describing the two ways of balancing ease of use versus airtight security:
Ease-of-use: core potential
Airtight security: plugin town
And we can always ship the plugin ourselves to let folks disable Email, but that feels like if it were in wp-admin that we’d be giving them just enough rope to hang themselves. 🙁
Now, none of this is finalized, so if you disagree, please voice your concerns in the comment section below. I’m hoping that we’ll get enough discussion that we’ll be able to confidently make a final decision on what path we’re taking at next week’s meeting — which will be on Thursday at 5pm Eastern / 22:00 UTC in #core-passwords
It’s been a couple weeks since our last update, but we’ve had some solid headway in the last couple days!
Current status of default providers:
Email: In and works.
FIDO U2F: In and works, but only for PHPPHPThe web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher 5.3+ (library dependency, non-trivial to revise for 5.2)
Backup Codes: In and works.
TOTP (Google Authenticator): Pull request open (several, actually), I expect to see it merged in the next couple days.
For the providers that are in and works, there may be minor issues either via code architecture or enhancements like better ui / ajax or whatnot — it’s just easier to solve those via small pull requests to master, versus endlessly debating in a pull request without actually merging it in. 🙂
Application Passwords are also included in the pluginPluginA plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party currently, however I’m not sure whether they should be a part of it or not in the end — they are included to allow users who use two-factor authentication to still use xml-rpc functionality, which can’t support two-factor authentication.
For TOTP, we will need to be able to generate QR codes, and the de facto standard library I’ve found for generating them locally seems to be https://github.com/kazuhikoarase/qrcode-generator — which has both PHP and JS implementations and is MIT licensed. I’m currently leaning towards the JS implementation, but I’d be fine with PHP instead. Either way works just as easily.
Last week we merged in the functionality to support fallback methods and have a great pull from @valendesigns to better automate the workflows and systems, as well as adding in some unit tests — https://github.com/georgestephanis/two-factor/pull/8
We also need some Design help with some flows and options screens, so if any designers are interested in pitching in, let me know! 🙂