“Don’t forget to check your pockets for lint!”
It was closed-sourced initially, for no other reason than it was experimental and didn’t want to make a promise it was coming without it being proven.
Without further ado, I give you Jetpack Force 2FA!
On multisite installations, it forces all users to use the SSO+2fa since there isn’t a reliable way to know if a particular user is an admin on any site of the network (since once they’re logged in on one site, they’re logged into them all).
On single-site installations, if logging in with a traditional username and password, it’ll check if the user is an admin or not. If so, it’ll kill the login attempt. If logging in with SSO, it’ll either use the pre-established connection between the local user and the WordPress.com user, or it’ll automatically accept if the e-mail addresses of the two accounts match.
It is pretty helpful for us at Automattic, since it gives us a pretty easy way to get the benefits of 2FA on our Jetpack sites without having to do anything extra.
This is still pretty far from perfect. Long-term, I like the WordPress Feature Plugin that is exploring adding 2FA directly to Core. The plugin, being developed on GitHub and available from WordPress.org, adds an extendible framework to add two-factor methods.
Out of the box, it includes methods for e-mail, TOTP (e.g. Google Authenticator or Authy), backup codes, or FIDO U2F (a special USB key that when connected to the computer provides the second authentication factor). It’s going to be a nice addition to WordPress if it lands, but even if it doesn’t, can still get the benefits of 2FA via Jetpack2.
- Two-factor, or two-step, authentication is when you need to login with two separate items—usually something you know and something you have. In Jetpack’s case, you’ll need to know your password and need to have your mobile device, either with an app installed to provide a code or ability to recieve SMS. ↩
- The 2fa plugin and Jetpack SSO doesn’t quite work nicely together yet, but we’ll get them working together soon enough. ↩
Andy Nacin gave this talk today at LoopConf in Vegas. In one sense, it is in the same vein as my Emoji, WordPress, and You post.
There were plenty of vocal critics about adding emoji support natively to Core and some still are, with the twemoji JS loader being enqueued on the front end of all sites starting with 4.2 unless a plugin is added.
Emoji was just a front for adding support for four-byte characters—emoji, Han (Chinese/Japanese/Korean) characters, and so on. Plenty of people would only see this as an improvement for emoji, but for a large amount of the world, it would lower the language barrier—literally the ability to better handle their native language—to using WordPress.
Nacin drops the other piece of this. Emoji was a front for four-byte characters which, for all of the good that it does in and of itself, was a front for an incredible fix for an incredible security bug.
Even if you don’t understand every word, Nacin does a good job explaining the problem in the video and worth the 35-minute watch time.
tl;dr: This bug was 💩. It would set the 🌍 on 🔥. All better now.
Major props to the Core Security Team who fought with this for years in an effort to squash the bug dead. 🐛