Howdy, all! I’m back, and we’re getting the Two-Factor Train rolling again!
We had our first meeting yesterday at the usual time (22:00 UTC / 5pm Eastern) in #core-passwords.
https://wordpress.slack.com/archives/core-passwords/p1449784908000119
Following some critical feedback and discussions both at the Community Summit and at WordCamp WordCamps 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-CLI WP-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 Rep A 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 FTP FTP 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 SSH Secure 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 admin (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 Core Core is the set of software required to run WordPress. The Core Development Team builds WordPress., and would be better left as a plugin A 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 Multisite Used 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 filter Filters 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
#feature-plugins, #two-factor, #updates
You must be logged in to post a comment.