WordPress.org

Make WordPress Core

Updates from George Stephanis Toggle Comment Threads | Keyboard Shortcuts

  • George Stephanis 8:23 pm on February 23, 2016 Permalink
    Tags: , , ,   

    REST API Authentication 

    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 core. That isn’t to say that we value the security any less, but rather that we also view the UX 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.

    Authentication Scheme

    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:

    • HTTPS — WordPress cannot guarantee that the site will be hosted on a HTTPS infastructure, and as such, any API 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.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 plugin territory at its current iteration.

    Probably some other points I’m missing, but those felt like the major two.

    Authentication Scope

    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-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 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

     
    • austinpray 8:45 pm on February 23, 2016 Permalink | Log in to Reply

      WordPress should support HTTPS as the default rather than an enhancement.

      • George Stephanis 8:55 pm on February 23, 2016 Permalink | Log in to Reply

        Unfortunately that isn’t something that WordPress has any control over — it’s up to hosts and users, as it’s server configuration.

        • Jeremy Clarke 4:13 pm on February 25, 2016 Permalink | Log in to Reply

          I’d say WP should imply that all users use HTTPS, and most hosts (at least Dreamhost) will be making it a default now that Let’s Encrypt makes it free (if not easy) for them to do so.

          IMHO having a “if you’re not even running HTTPS how do you expect your app interactions to be secure?” policy would be very fair.

          Having an in-core solution that is disabled when HTTPS isn’t available also seems fair, and would be a great way to turn up the hustle for hosting providers.

    • jteague 9:20 pm on February 23, 2016 Permalink | Log in to Reply

      I realize this throws a wrench into the potential works, but I would not be in favor of either an oauth or app password schema that tries getting around HTTPS. I don’t know application cases where HTTPS would not be a requirement up front in the app build process. Certainly none we’ve ever built.

      With Let’s Encryptin at near pre-release, and the otherwise very low financial burden on SSL these days, I think it better to take the lead than to encourage poor security or worse the impression of security that doesn’t exist. Thanks.

      • thetechnuttyuk 10:25 pm on February 23, 2016 Permalink | Log in to Reply

        I agree, with Google making moves towards a HTTPS only internet anyway, it’s clear that some things have to be purposed specifically for HTTPS for them to grow, putting features like this in HTTP is frankly waiting for trouble to happen, it’s also decreasing the reasons that someone should switch.

        Not only that, I can’t think of one other application take doesn’t force HTTPS security on things like this, not forcing HTTP is building huge security flaws in WordPress, flaws that hackers will figure out and will use to their advantage.

        People should know that the only way to be secure is HTTPS, too many people don’t realise the full dangers of HTTP yet.

    • Eric Andrew Lewis 10:28 pm on February 23, 2016 Permalink | Log in to Reply

      I think we should consider cookie-based auth for third party apps, in some form. It is already the de facto auth scheme. The architecture for it exists, we’re familiar with it, and we’ve decided the scheme itself is secure enough to manage your entire WP admin.

      We could create app-specific cookies that have limited permission scope (e.g. “this app wants to edit your posts” or “this app wants to edit your posts and your users”).

      We could ensure that apps don’t store your credentials by offering a login screen that apps send you to auth the app, similar to OAuth flows (e.g. wp-login.php?requested_permissions=edit_user&edit_posts&sendback_url=https://coolapp.com). After auth WordPress could redirect you back to the site with the app cookie (https://coolapp.com?wp_authed_your_app=true&app_cookie=w33ruhibd32f8yh3rf823yfh3ifn3=).

      • George Stephanis 3:50 pm on February 24, 2016 Permalink | Log in to Reply

        Apart from being relatively fragile, I feel that this is an incredibly dangerous idea.

        As soon as an app has your main password, we lose the ability to regulate what the app does. We can’t ‘force’ them to take a weakened privileges cookie, they could just spoof a browser and get a full cookie, at which point they can do anything from deleting all your posts to uploading and activating custom plugins (even ones that are not vetted and in the repository), to changing your user password and email address to entirely hijack your site.

        Plus, if they have your plaintext password, there is no guarantee that the app would keep it secure. For example, Pressgram — which operated via XML-RPC — uploaded user passwords in plaintext to a remote server. I don’t like the idea of encouraging users to give their plaintext wp-admin password to any app, from a security and trust perspective. (I’d far prefer an Application Password that can’t be used to access things that aren’t in the REST API — it feels much more security conscious).

        • Eric Andrew Lewis 4:39 pm on February 24, 2016 Permalink | Log in to Reply

          > As soon as an app has your main password

          Please note the part where I said “we could ensure apps don’t store your credentials by offering a login screen on [your WordPress site])

          • George Stephanis 4:48 pm on February 24, 2016 Permalink | Log in to Reply

            Ah, sorry, my mind jumped to our previous conversation.

            At the point where they’re not entering their main password — but they are instead just clicking to approve the application and getting the auth token redirected back, that feels very much like a minor UI addition to what we’ve built out with Application Passwords.

          • George Stephanis 5:01 pm on February 24, 2016 Permalink | Log in to Reply

            I just wrote this up as a rough idea for Application Passwords — is it roughly what you had in mind? https://github.com/georgestephanis/application-passwords/issues/36

            • Eric Andrew Lewis 7:54 pm on February 24, 2016 Permalink

              Yes, that looks good.

              It seems our visions are merging, and either using app passwords or cookies would be an implementation detail.

            • Jeremy Clarke 4:20 pm on February 25, 2016 Permalink

              +1 This makes sense. The more it feels like authenticating a Twitter/Facebook app the better and so far this sounds similar.

    • Mike Nelson 1:11 am on February 24, 2016 Permalink | Log in to Reply

      Wait wait wait… I’d like to take a step back. Why are we so tied up trying to secure the WP API authentication for HTTP users, meanwhile they’re providing their password to the wp-login page unecrypted EVERY time they log in? If I were a hacker, I wouldn’t care what kind of complex security got implemented for the WP API, I can already just setup on a public wifi and sniff all requests to wp-login.php for passwords. It’s too easy. I already have a way in.

      So let’s assume for a moment we force everyone who wants to use the WP API to use oAuth1a and jump through all those hoops. Great, all those HTTP users’ passwords are safe…. wait, no they’re not. They never were. They’ve provided their password unencrypted over the internet every time they’ve logged in.

      If someone doesn’t have HTTPS enabled, their password isn’t secure. No matter how secure we make it with the WP API, it was never secure to begin with. They need HTTPS if they want security. Using the WP API securely should start with the assumption that they’re using HTTPS. With that assumption I think we can give users a good experience.

      Am I totally off base with these thoughts?

      • George Stephanis 3:54 pm on February 24, 2016 Permalink | Log in to Reply

        I wouldn’t be terribly opposed to the idea of just stating that if a site doesn’t support HTTPS, that ‘on your own head be it’ basically. If you choose not to support good security protocols, you’re knowingly accepting the risks.

        But a lot of users are ignorant of the risks that they’re exposing themselves to, and we need to do what we can to keep them safe. As developers, that’s our job.

        So it’s tricky. There is no truly great solution that we’ve found yet. OAuth 1.0a uses a secret to ‘sign’ requests to the site so that they can’t be used in replay attacks, and the secret is never sent over the wire. So that works, but it’s dependent on the arguably bad UX of having an application registered before user authentication.

        • Mike Nelson 5:36 pm on February 24, 2016 Permalink | Log in to Reply

          I hear ya but it already is “on your own head be it”.

          So for HTTP sites, their password has already been exposed over the net. So from that starting point, none of the authentication methods considered will help, or really can. It’s incorrect to say “oAuth1a is secure for HTTP” because the process used to setup and configure oAuth1a was insecure to begin with.

          For example with application passwords being used over HTTP, I had originally thought it was safer than just Basic Auth because the user securely sets up and sees their application passwords in the wp admin. But the wp admin is being served over HTTP, and so are those application passwords. Meaning those application passwords have already been exposed, and so has their original password for that matter. So even though I agree we need to do what we can to keep users safe, I don’t see how we’re helping. It seems like an impossible task. We’re starting with an insecure system where the user’s password is already exposed: we don’t know if the user clicking the button in the wp admin is the real user, and we don’t know if we’ve given the application passwords to the real user, and we don’t know if it’s the real user who’s authorized the applications in the oAuth plugin’s admin. We began the whole process not knowing if this was the real user. How are we going to improve that?
          The only thing you can say is that intercepting a user’s password is EASIER with the Basic Auth authentication for the API because their password is sent on every request, whereas in the wp admin it’s only sent once.

          • George Stephanis 5:43 pm on February 24, 2016 Permalink | Log in to Reply

            If you’re originally generating the password or secrets over a VPN or on a secure home network, there’s very little likelihood that the initial generation would be intercepted. Then you can use the signing over less secure networks — like your local Starbucks — with more comfort.

            Obviously I’m not accounting for government-scale surveillance, merely pointing out that if the initial exchange is free from prying eyes, you’re probably fine with OAuth 1.0a signing.

            • Mike Nelson 5:56 pm on February 24, 2016 Permalink

              yeah ok that’s a good point

            • voldemortensen 6:11 pm on February 24, 2016 Permalink

              To play the advocate, how many regular users do things over a VPN, and in reality, home networks aren’t that secure. Tools like reaver and aircrack-ng make it trivial to do MITM attacks, or even compromise the whole network. Granted, someone would have to be specifically targeting you, but those tools are readily available.

            • George Stephanis 6:20 pm on February 24, 2016 Permalink

              Sure, it’s totally feasible you could get hit on your home network. My point is just that it’s significantly more likely on a public one, and measures can be taken client-side to mitigate.

    • John P. Bloch 2:07 am on February 24, 2016 Permalink | Log in to Reply

      I wonder if it might also make sense to further break down the content and “full” scopes into read and write. That way, applications that don’t need to modify user data but would like to read it could better put their users at ease (and same with reading content without being able to write it, perhaps for analytical or aggregation purposes).

      • George Stephanis 3:56 pm on February 24, 2016 Permalink | Log in to Reply

        Maybe? But that feels more like plugin territory. I’m not sure if an ‘options grid’ of limited vs full and C/R/U/D (or just simply read vs write) would be in any way intelligible to your typical user.

        Whether to grant access, and limited vs full feels to me — as a quick gut check — about as far as it would be wise to go.

      • Jeremy Clarke 4:27 pm on February 25, 2016 Permalink | Log in to Reply

        FWIW it wasn’t easy but I think FB/Twitter/iOS/Android have trained people to think in terms of granting permissions for specific tasks and denying others. At least they got some people on board with the concept.

        The matrix/list would have to be simple, but something like “this app wants to: READ your content, WRITE new content but doesn’t need to CHANGE settings” would probably make sense to most people.

        Ideally apps would be able to indicate what they need, and users could then choose whether to grant access to all of it or some of it.

    • Eric 4:47 pm on February 24, 2016 Permalink | Log in to Reply

      > 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,

      Please do not assume that current or future mobile apps are “legacy” or that they do not aspire to be a “full control” application. On the contrary, the goal is for a very rich experience beyond what is supported by the legacy XML-RPC API.

      • George Stephanis 4:49 pm on February 24, 2016 Permalink | Log in to Reply

        Sorry Eric! I was trying to refer to apps that communicate exclusively through the legacy XML-RPC API (what will eventually become legacy versions of the WordPress mobile apps). Worded badly on my part.

    • javilopezg 11:25 pm on February 24, 2016 Permalink | Log in to Reply

      Hi everybody, here a new one with a blog using WordPress.

      I was testing the REST API and it is clear to me that a change in the authentication is needed. It does not have any sense to create different applications for different websites. A solution could be a central repository as George suggest, but if you do not want to do that I think that you do not have to do that.

      I will use OAuth 2 to explain my self because in my opinion is really more simple and better and clear and… in comparison to OAuth 1.

      • coolapp.com is the site of the app
      • cooldev.com is the WP site of the developer in which I defined the app as multitenant
      • cooluser.wordpress.com is the WP site of the user who wants authorize coolapp.com to interact

      01- User access to coolapp.com and says “Hey, I want to use this cool app”
      02- coolapp.com ask for its server and user writes cooluser.wordpress.com
      03- coolapp.com ask to cooluser.wordpress.com to identify the user
      04- the user writes his credentials in cooluser.wordpress.com
      05- cooluser.wordpress.com redirects to coolapp.com with a code saying “Yeah, this man is my man”
      06- coolapp.com then ask to cooldev.com and says “Hey, I have a user with a code that wants to acces to the resource cooluser.wordpress.com and I am the coolapp.com (this is my client_id and this my client_secret)”
      07- cooldev.com generates a token
      08- cooldev.com says to cooluser.wordpress.com “Hey, I just generated this token that expires in 3600 seconds and its privileges are read and write”
      09- cooluser.wordpress.com says “I would prefer not to work, but you know, it’s ok”
      10- cooldev.com sends the response to coolapp.com with the token
      11- then coolapp.com using the token, can now ask to cooluser.wordpress.com to do some stuff

      If you look at this diagram https://tools.ietf.org/html/rfc6749#section-1.2

      Client = coolapp.com
      Resource Owner = cooluser.wordpress.com
      Authorization Server = cooldev.com
      Resource Server = cooluser.wordpress.com

      The RFC says:

      “The interaction between the authorization server and resource server
      is beyond the scope of this specification. The authorization server
      may be the same server as the resource server or a separate entity.
      A single authorization server may issue access tokens accepted by
      multiple resource servers.”

      but with some conversation like the one in 8 and 9 it could be resolved.

      • javilopezg 6:39 am on February 25, 2016 Permalink | Log in to Reply

        I did a mistake last night. Is the resource owner who says what policies the user authorizes, so at point 08 cooldev.com only says “Hey, I just generated this token that expires in 3600 seconds”.

        Regards

  • George Stephanis 7:15 pm on February 16, 2016 Permalink
    Tags: , , ,   

    API Authentication discussion! 

    I was chatting with @rmccue and we though it’d be a good decision to have an open discussion regarding potential avenues for API Authentication on Thursday, February 18th at 22:00 UTC in the #core-passwords channel in Slack.

    We’ll be addressing everything from OAuth 1.0a, OAuth 2.0, Application Passwords, and what limitations should be used to scope assorted tokens.

    Relevant background reading: http://stephanis.info/2016/02/14/on-core-rest-api-authentication/

     
    • simonrcodrington 8:04 pm on February 16, 2016 Permalink | Log in to Reply

      Interesting article, thanks for sharing your thoughts.

      When it comes to the API and how it should work going forward, I’m happy with both of these scenarios:

      1 – Once you’re athenticated you can hit all endpoints and perform all admin actions (the onus can be on the user to a accept the risk)
      2 – The user authorises connections only to set API endpoints that could be organised by potentially their risk / importance

      Either way, I’m happy progress with the API is making it into core

  • George Stephanis 3:16 pm on January 27, 2016 Permalink
    Tags: ,   

    The Two-Factor Plugin is currently on a brief hiatus, while we work on splitting off it’s Application Passwords feature into a smaller, solo feature plugin.

    https://github.com/georgestephanis/application-passwords/

    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 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 admin UI 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 Core has to use because we can’t guarantee HTTPS, 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.

    Screen Shot

    Code reviews, issues, and pull requests are very welcome.

     
    • Mikel King 3:53 pm on January 27, 2016 Permalink | Log in to Reply

      Awesome thanks for this!

    • Laurens Offereins 4:29 pm on January 27, 2016 Permalink | Log in to Reply

      Interesting. Am I wrong to say this is like GitHub’s access tokens? Would this be useful for, let’s say, making user-specific RSS feeds, allowing private posts in the feed? I’ve for long wanted a unified interface for creating user-specific access keys.

      • George Stephanis 8:33 pm on January 27, 2016 Permalink | Log in to Reply

        Hrm, well, RSS feeds don’t ordinarily require authentication, but I guess you could use it as authentication on a JSON API endpoint that gives similar data and tailor it to a user.

    • Scott Kingsley Clark 5:56 pm on January 27, 2016 Permalink | Log in to Reply

      I love this feature, looking forward to it!

    • thetechnuttyuk 4:31 am on February 11, 2016 Permalink | Log in to Reply

      Great feature, but please make sure that if it is added into core, it can be completely turned off by the administrator, I don’t want to have to go into some random piece of code every time I update WordPress, and I don’t want yet another plugin to use in order to turn this feature off site-wide, it should be a standard option to turn it off completely for the admin, or not included in core at all.

      • thetechnuttyuk 4:34 am on February 11, 2016 Permalink | Log in to Reply

        This is not a simple WordPress addition, this changes the security of WordPress, if it is not optional, it shouldn’t be an option, the same goes with 2FA.

  • George Stephanis 3:52 pm on December 11, 2015 Permalink
    Tags: , ,   

    2FA! 2FA! 2FA! 

    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 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). 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) 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, Database, or SSH.

    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.

    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, and would be better left as a plugin.

    (yes, I know Multisite 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 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

     
    • Samuel Wood (Otto) 4:00 pm on December 11, 2015 Permalink | Log in to Reply

      +1 for “email as an always-on fallback” and “must verify a code via email to even turn 2FA on in the first place”. Best solution.

    • chriscct7 4:01 pm on December 11, 2015 Permalink | Log in to Reply

      For emails, what about using .org as an email provider where the site would ping .org and .org would send out the email?

      Also with text messages you don’t need to use a third party service. You can just use a library that maps carriers to their standard email to SMS address and then send an email (or .org sends an email) to that email. An example is https://github.com/JeffMatson/WP-SMS-Notifications/blob/master/carrier-list.php

      • George Stephanis 4:04 pm on December 11, 2015 Permalink | Log in to Reply

        Doesn’t work for all carriers. For example, Project Fi (which I’m on) doesn’t have an email to txt message gateway.

        • chatmandesign 4:05 pm on December 11, 2015 Permalink | Log in to Reply

          Would be a nice option to provide for those on carriers that support it, but definitely not something that can be relied upon for all users.

          • George Stephanis 4:07 pm on December 11, 2015 Permalink | Log in to Reply

            It also is something that would be easy to forget to update if you change cell phone carriers. Then the old carrier’s gateway would fail silently.

      • Mark-k 4:35 pm on December 11, 2015 Permalink | Log in to Reply

        I think that free SMS is mainly a US thing. I don’t know of any email to SMS gateway for any of the companies operating in israel.

        Making wordpress.org an email relay will just increase the option it will be marked as spammer, and there is the privacy aspect as well.

        • George Stephanis 4:44 pm on December 11, 2015 Permalink | Log in to Reply

          I agree, plus I hesitate to route something as critical as login through one central server for the default fallback core implementation. Feels like putting too many eggs in one basket.

          • Jon Brown 5:28 pm on December 11, 2015 Permalink | Log in to Reply

            and for those that travel internationally… SMS isn’t always available (changed SIM Cards, outside mobile coverage but on WiFi, etc..)

    • chatmandesign 4:02 pm on December 11, 2015 Permalink | Log in to Reply

      Is 2FA really something that should be built into core? It seems like you provide some good arguments why 2FA should be managed by technical administrators and security experts, not managed by end users at all.

      To be honest, I’d rather see federated login support built into core… Then the people who want 2FA can simply choose a login provider that has the technical chops to provide 2FA in a way that’s actually secure (e.g., Google).

      • Mikel King 4:29 pm on December 11, 2015 Permalink | Log in to Reply

        I have to agree leaving 2fa to the realm of 3rd party systems makes better sense.

        I think user base would be better served with having password expiration, character diversity, character length and history retention as well as session duration limit settings built into the core.

      • thetechnuttyuk 1:46 pm on January 25, 2016 Permalink | Log in to Reply

        I agree with this, 2FA should stay with the people who know what they are doing. I think it is okay to maybe add the option of WordPress 2FA within something like Jetpack, or to provide a tip message within Core to download the plugin, as WordPress built 2FA might be eaiser to those who don’t know how to set-up this as well.

        But I don’t think it should be built in.

        Third parties can do a much better job, a great example being Duo Security, who currently offer an awesome all-around solution that integrates directly with WordPress, we use it on all our sites and it works perfectly.

    • Varun Sridharan 4:02 pm on December 11, 2015 Permalink | Log in to Reply

      +1 For Emails .

      Nice feature 🙂

    • Omaar Osmaan 4:03 pm on December 11, 2015 Permalink | Log in to Reply

      +1 for email as an always-on fallback, and to verify a code for the first place.

      May be “require a constant in `wp-config.php` to *disable* 2FA”- should be a doable, too.

    • Mikel King 4:21 pm on December 11, 2015 Permalink | Log in to Reply

      I understand you feeling about the wp constant; however, why not reverse that process. Where normally we would have to define a constant to turn something on why not make it on by default and if you get into trouble you have to define DISABLE_2FA?

      That being said I just completed lighting up DUO Security’s 2fa system on our production sites and overall the users have embraced it. So I believe that it’s ready for primetime if you can make it work.

      On a side note does anyone else find the discussion of enhanced security and FTP in the same breath ironic?

      • George Stephanis 4:28 pm on December 11, 2015 Permalink | Log in to Reply

        I understand you feeling about the wp constant; however, why not reverse that process. Where normally we would have to define a constant to turn something on why not make it on by default and if you get into trouble you have to define DISABLE_2FA?

        We will be including at least one constant / filter or something to that effect to disable 2fa.

        I personally think filters is better than constants, as you can have multiple plugins messing with a filter no problem, but if two try to define the same constant, it’s sad christmas.

        • Omaar Osmaan 4:30 pm on December 11, 2015 Permalink | Log in to Reply

          From a end-user perspective, constants are easy to assign- as a Dev, I would prefer the filter, yes.

        • Mikel King 4:33 pm on December 11, 2015 Permalink | Log in to Reply

          If a user did something stupid locking themselves out would they need an mu-plugin to trigger the filter so that they could attain access again?

          • George Stephanis 4:39 pm on December 11, 2015 Permalink | Log in to Reply

            You mean with the proposed always available Email fallback that just emails them a code?

            • Mikel King 6:48 pm on December 11, 2015 Permalink

              I was thinking more of a mu-plugin that unlocks that user’s account. Similar to how you described the constant definition below. The advantage is that you could apply the filter to multiple account in said plugin. However the disadvantage is that most users & general site admins are not very savvy when it comes to mu-plugins so it’s a technical barrier…

          • Ipstenu (Mika Epstein) 10:40 pm on December 11, 2015 Permalink | Log in to Reply

            The issue there is that a required MU plugin means they have to have file access to the system AND know how to install that.

            And when they don’t, they’ll be putting undue burden on hosts who have to walk people through things.

            My issue (and this isn’t news to George) is that users do NOT know how to dig themselves out of holes, and if we’re throwing them into one (TFA) we damn well have to make sure they have a ladder accessible to the majority of users.

            Sadly that means email and confirm code before locking in. It’s the lowest common denominator.

        • idealien 6:13 pm on December 11, 2015 Permalink | Log in to Reply

          “We will be including at least one constant / filter or something to that effect to disable 2fa.”

          +1 for wp-config constant required to enable the 2FA feature.

          Please keep the use-case of sites that use LDAP for external validation in mind. All UI / strings / messages that trigger related to WP passwords should respect that constant / filter as any reference to a WP password just adds user confusion.

          If / when this does come to core – please set a higher standard than 4.3 release notes did at communicating the new messages and hooks to disable email notifications. Paint a clear picture between new / updated functionality and new / updated constants, hooks, filters, etc related to it.

    • AITpro 4:32 pm on December 11, 2015 Permalink | Log in to Reply

      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.

      In my experience over the past 5 years, I am seeing an increasing trend in automatic emails (PHP mail() vs direct emails sent from a computer email application like Outlook) being rejected due to anti-spam measures on sending and receiving Mail servers and 3rd party email services that automatically blacklist Mail Server IP addresses. At this point in time I would say 25% automated email failure/rejection is an accurate number. I imagine that that number will continue to increase steadily. So logically a fallback system like generating a non-email time sensitive encrypted/hashed string may be a smart move in the long run. Example: example.com/unlockme.php?action=foo&key=EwtNARIrmZEWBRTvYzdn&unlock=blah

      • AITpro 4:37 pm on December 11, 2015 Permalink | Log in to Reply

        Oops forgot to mention this very important point: When generating/sending emails from yourself to yourself from your own server there is not typically going to be a problem with automated emails being rejected. The problem occurs when dealing with different sending and receiving Mail Servers. ie someone is using a different Mail Server other than the origin Mail Server for that website.

      • George Stephanis 4:41 pm on December 11, 2015 Permalink | Log in to Reply

        We’re only keeping Email on as an emergency fallback. There are other providers that will be also included, such as TOTP (Google Authenticator), Backup Codes kept in a safe place, FIDO U2F usb security keys, and others.

        So it’s not a ‘purely email’ 2fa system. Just that email will always be available if you lose the other methods.

    • CotswoldPhoto 4:36 pm on December 11, 2015 Permalink | Log in to Reply

      My feeling is that you have 2 levels of user; those who are happy to edit wp-config.php and those that are not. So, why not add a switch in wp-config.php that by default is commented out? If a user is capable and willing to uncomment it to enable 2FA, they have no need of an emailed backdoor password. If they are locked out, they can edit the wp-config.php file to switch it back off. Then, a second level of enabling that requires the user to enable it in admin, where it will send out a ‘rescue’ email, or maybe just show the backdoor one time passkeys for them to copy? Once off the page, the keys are hashed. I seem to recall this is what Joomla used to (may still does?) do.
      Why should 2FA be in core? Security like this SHOULD be. Only with it in core will all the variety of user and alternative login plugins adopt and support the core code.

      • George Stephanis 4:43 pm on December 11, 2015 Permalink | Log in to Reply

        So, why not add a switch in wp-config.php that by default is commented out?

        For new installs, perhaps, but on updates wp-config.php is never touched, so this wouldn’t help most sites.

        • CotswoldPhoto 5:12 pm on December 11, 2015 Permalink | Log in to Reply

          But you could allow the more competent user to add the line? I have edited the wp-config.php file of every site I have ever made in WordPress.

          • George Stephanis 5:15 pm on December 11, 2015 Permalink | Log in to Reply

            Sure, and you’re certainly not a typical user, let alone those who don’t even know what FTP is. We need to do our best to make 2FA accessible to everyone, not just the privilege of the technically minded.

    • Brandon Kraft 4:48 pm on December 11, 2015 Permalink | Log in to Reply

      Another alternate idea: Infrastructure in Core, methods in plugins. At least initially.

      Instead of asking users to install possibly multiple, random plugins to provide multi-method 2fa, we put the infrastructure in Core, release the major methods via plugins (either a “special” status, a la the importers, assuming the #core-passwords group is willing to maintain it long-term).

      The current code allows for extending it through other plugins, so if new third-party solutions or new standards come out, Core provides an easy way to allow for that extendability while insuring some level of compatibility.

      /////////

      My fear with an e-mail backup, even if it is verified as working, could always stop working (moved hosts, shared hosts get blacklisted and the e-mail provider silently drops blacklisted e-mails). I’m not sure a way to ensure an always available 2fa method that isn’t open to some type of failure.

      • George Stephanis 4:50 pm on December 11, 2015 Permalink | Log in to Reply

        I really dislike shipping a whole infrastructure in core that does nothing, when we can easily provide solid implementations of some providers. It feels like we’re violating “Good Software should run Out of the Box”

    • Dave McHale 4:54 pm on December 11, 2015 Permalink | Log in to Reply

      Can you clarify the final point in the post? Would a filter/constant be available that disables the email functionality, or the 2FA itself?

      Similar to Brandon above, I’d be concerned with host failures, host moves, all sorts of variables that may change after-the-fact. While no solution will be perfect, I think, it seems sensible to me that at least a constant be provided for “if all hell breaks loose, set this constant in your wp-config to turn off 2FA entirely”. At least then a technical admin can disable the feature, log back in, and hopefully troubleshoot from there. As long as this is the case, I think the option provided definitely sounds like the most sensible of the alternatives listed.

      • George Stephanis 5:09 pm on December 11, 2015 Permalink | Log in to Reply

        Yes, regardless of everything else, there will be a constant to turn off 2FA. I’m thinking something like…

        `define( ‘DISABLE_2FA’, true );` — disables it entirely while the constant is in effect
        `define( ‘DISABLE_2FA’, 12 );` — disables it only for user ID 12
        `define( ‘DISABLE_2FA’, ‘bob’ );` — disables it only for username `bob`
        `define( ‘DISABLE_2FA’, ‘bob, jane’ );` — disables it for users `bob` and `jane`

        Some of these may be overthinking it, so I’m not sure what the final disable implementation will be, but all of these are feasible.

        • Brandon Kraft 5:13 pm on December 11, 2015 Permalink | Log in to Reply

          Should we have an UI for admins to tempoarily disable/reset/issue-backup-code for a particular user?

          (Or do we already? Haven’t ran the plugin on a multi-user site yet).

          • George Stephanis 5:14 pm on December 11, 2015 Permalink | Log in to Reply

            Yeah, we do already. Admins can disable other users methods just as they can change passwords and whatever.

            • Mikel King 6:43 pm on December 11, 2015 Permalink

              The real concern here is if it’s the admin that’s borked their 2fa access. I mean it is most important to ensure that every account with admin capabilities is using 2fa.

        • Dave McHale 5:20 pm on December 11, 2015 Permalink | Log in to Reply

          Nice. And I like those ideas. I would personally prefer to use them as one-off definitions, rather than allowing your fourth example with both users. If someone wants to turn it off for multiple users, I don’t see harm in making them just use two lines such as

          `define( ‘DISABLE_2FA’, ‘bob’ );`
          `define( ‘DISABLE_2FA’, ‘jane’ );`

          Still clean, and less potential for disaster while parsing out human-typed delimited input, too. Plus if you DO allow for multiple users by username, you would probably want to support multiple users by id, too, and that starts getting even messier, I think.

          Will per-user filters to disable 2FA be implemented by default as well? Will core support “2FA is turned on for this site, but you can check a box to have a single user opt OUT of using it”?

          • George Stephanis 5:21 pm on December 11, 2015 Permalink | Log in to Reply

            I see plenty of harm in that, insofar as a single constant can’t be defined twice. It’s a PHP thing.

            • Mikel King 6:40 pm on December 11, 2015 Permalink

              That’s exactly what I was thinking. I think the filter method may be the only way to hit multiple users at once.

          • George Stephanis 5:24 pm on December 11, 2015 Permalink | Log in to Reply

            Will per-user filters to disable 2FA be implemented by default as well? Will core support “2FA is turned on for this site, but you can check a box to have a single user opt OUT of using it”?

            Getting a bit out of scope for this discussion, but the filters will look something like

            `apply_filters( ‘user_can_2fa’, $configured, $user );` — or something akin to that, so you can use the filter to turn it on or off for either everyone or just specific users, based on their WP_User as passed to the filter.

            If you’d like to talk about this more in depth, please ping me in Slack? #core-passwords

        • Omaar Osmaan 1:59 pm on December 12, 2015 Permalink | Log in to Reply

          Multiple options for the constant looks good.

          But may be constant could be just to hard-disable the 2FA entirely- overriding the filters, and keep it simple. While the filter could provide all those flexibility to empower 2FA options.

    • rawrly 5:11 pm on December 11, 2015 Permalink | Log in to Reply

      Emailing a reset token for 2FA, is an ideal solution. Not only is it no-less secure than the current “forgot password” system, it leaves what is effectively evidence of tampering with someone’s wordpress site, on a third party server (the email server, assuming it’s hosted elsewhere.)

      Setting up an option in wp-config, i agree sounds odd. Wouldn’t the standard put this option setting in wp_options in the database? In cases where email reset tokens are not wanted, I’m sure that advanced user could use phpmyadmin or myql on the CLI just as easily as they could use vim/nano/pico/emacs. (What I mean here, it sounds like a lot of extra work for something to be non-standard and help a very small number of users)

      You however did not give a lot of credit for one-time use emergency tokens. Basically a “reset 2fa token” that never expires until deleted or used. These are somewhat of a standard for cases where touching the database is not an option (possible on some hosting platforms I am sure, if not for users being unfamiliar) and email might not be trusted enough verification (again, a fringe case, but maybe email service is broken on the WP site’s server). They wouldn’t have to be required to be generated if not wanted, and should not be the only option for resetting 2fa, but can be one more option that would cover almost all (including the most fringe) cases for 2fa users wanting access in case of emergency lost second factors (and as secure as their personal laptop/desk are.)

      • George Stephanis 5:39 pm on December 11, 2015 Permalink | Log in to Reply

        You however did not give a lot of credit for one-time use emergency tokens. Basically a “reset 2fa token” that never expires until deleted or used.

        We already have these fully implemented. But we can’t rely on them, because humans lose things.

        • TobiasBg 5:41 pm on December 11, 2015 Permalink | Log in to Reply

          One idea here could also be to show regular reminders every two-three months or so, when a user logs in, about whether a backup email address is still correct, how many backup codes have been used, etc., similar to how Google does it.

        • Mikel King 6:51 pm on December 11, 2015 Permalink | Log in to Reply

          Or worse forget to even save those tokens somewhere offline for future use. Or even worse yet store those OTP’s in a email folder that then get’s hacked and well Bob’s your uncle…

        • rawrly 7:51 pm on December 14, 2015 Permalink | Log in to Reply

          As long as it’s an option, that’s great. It certainly is a bit much to ask as the only solution for resetting 2FA.

    • Jon Brown 5:40 pm on December 11, 2015 Permalink | Log in to Reply

      Yes in core. Yes email fallback, but… have the ability to _disable_ email fall back via define in wp-config.

      Further, I definitely would like the ability to restrict 2FA to certain user roles. because:
      1) I don’t want to run into having to support membership users that enabled 2FA because it was there…
      2) I equally like the idea of mandating the administrators and editors use 2FA.

      Currently we handle (2) by using 2FA on /wp-login.php, but not requiring it on our custom /login pages. If an admin tries to login on /login they get denied and redirected to /wp-login.php. Pippin wrote a quick plugin for this on Restrict Content Pro: https://github.com/pippinsplugins/rcp-fatwpl/blob/master/rcp-force-admins-to-wp-login.php

      • George Stephanis 8:11 pm on December 11, 2015 Permalink | Log in to Reply

        but… have the ability to _disable_ email fall back via define in wp-config.

        Why a defined constant? I’d been expecting that we’d using a filter for that, but very eager to hear arguments in favor of a constant instead.

        Further, I definitely would like the ability to restrict 2FA to certain user roles. because:

        Both of these restrictions, forcing it on or off, will be totes doable, I expect, either globally, or on a user-by-user basis (and therefore on a user role basis)

    • Philip Ingram 6:03 pm on December 11, 2015 Permalink | Log in to Reply

      Yes in core, yes to email feedback, yes to disable via constant, yes to the idea of a unique randomized url for a traditional login fallback.

      Personally while I use a 2F plugin that works very well I can’t help but feel the dread of knowing this doesn’t really solve any of my REAL problems security-wise with my sites. While my sites don’t get hacked I still feel the pain of the hack attempts.

      Hackers bots are killing the web for WordPress sites. Every site I work on eventually becomes discovered and expects repeated hack attempts (sometimes upwards of thousands of hits per minutes) because there is no seamless and easy way to obscure that the site is running on WordPress. Changing the url and disabling xmlrpc is not a solution either but helps in some cases.

      I think the problem is much worse than protecting the login credentials. We need to be looking at how we can approach the problem of dealing with the constant knocking at the door costing against server resources and bandwidth resulting in poor performance and excessive hosting costs.

      Normally in a one-off scenario I would think this the responsibility of the IT/Server arena not the website application software however when one product powers 25% of the web, I think the responsibility crosses the barrier as only my WordPress site’s experience this problem on such a massive scale.

      There is such a wide number of hijacked IP addresses, blocking at the web server has very little effect and doesn’t address the amount of hits. Especially for those running on inexpensive shared servers hosting upwards of 6000 sites where the large majority are receiving constant bot activity specifically targeting WordPress sites.

      For some, the only approach for relief is to use a security DNS service that is already aware of the large majority of compromised IP addresses and block the attack before it even hits the web server. This comes at a price. Additionally, the different server builds adds complexity whether apache, nginx etc. so my thoughts are strongly leaning towards a way to finally be able to obscure a site is running WordPress. Is a free 3rd party filtering (firewalled DNS) service out of the question for an open source project like this? Could the means justify the cost of WordPress fixing the “WordPress” inherited security problem?

      On a similar scale, we see this problem spiraling out of control much like email spam where even the age old tradition of blacklisting isn’t very efficient anymore and more often a nuisance for legitimate users.

      • George Stephanis 8:17 pm on December 11, 2015 Permalink | Log in to Reply

        yes to the idea of a unique randomized url for a traditional login fallback.

        This feels just like the Backup Codes provider we already have, except instead of being per user, it’s global — and therefore a touch more dangerous. It would let anyone that knows the randomized url thingy bypass 2fa on any other user account, if it’s global. If it’s per user, then it’s just a more complicated version of backup codes.

        While my sites don’t get hacked I still feel the pain of the hack attempts.

        Have you considered the Protect module in Jetpack? It’s good at saving server load by exiting early on attempts from bad ip addresses. Unfortunately, it’s not something that can be done in Core WordPress, as it’s dependent on a third party server identifying the botnets trying to break into sites.

        Anyway, as fascinating as the topic is, I’m afraid it’s out of scope for this project, apart from 2FA making WordPress more difficult for botnets to crack into, and therefore less appealing.

    • Philip Ingram 8:55 pm on December 11, 2015 Permalink | Log in to Reply

      In regards to the randomized url, yes global is much simpler and if somehow a hacker figured out /wp-login.php?7c850yqbaude4cxr=ts43ng0t564dopl0 they’d still have to have a real username to brute force against but likely get locked in the first few attempts anyway. Another fail safe might be to email notify an admin of the attempt of a failed login via that obscure url so it could be changed immediately.

      I’d prefer wp-login.php was no longer a constant. I know obscurity is not considered a good practice for website security but the lack of obscurity it what puts my sites on the radar in the first place. No one seems to care about hacking my non-wp sites.

      While not off topic by any means I do understand this is out of scope but thanks for allowing me to post my thoughts regardless.

    • dmccan 11:01 pm on December 11, 2015 Permalink | Log in to Reply

      If I read the old session notes correctly, this discussion is really the lowest common denominator fallback for sites that cannot or don’t implement additional 2FA options or for times when alternatives aren’t available (such as cell phone loss). For example, it looks like there is to be support for using the Google Authenticator service. It has clients for Android and iOS. So, I think you are on a good track with the plan as outlined.

      FWIW, WordPress.com has 2FA with SMS recovery. I know JetPack is separate, but perhaps the JetPack team would allow JetPack users to register their cell phone number for account recovery as another option.

    • Ryan Hellyer 4:34 am on December 12, 2015 Permalink | Log in to Reply

      It sounds like you guys have done an excellent job on this. The email backup solution sounds perfect.

    • Jon (Kenshino) 10:27 am on December 12, 2015 Permalink | Log in to Reply

      Loving the discussion

      But just to make things clear…. When the Support Team suggested having email by default as a fall-back, it isn’t the same as having it as the only fall back.

      Our suggestion really focuses on – is there any easy, non-code way for the normal users to get back to logging in if they really have no idea what they’re enabling.

      Once they’re comfortable and/or they are advanced users, they can swap out the email fall back to some other fall back. But they must always have 2 levels of providers to allow them to login. (Or possibly use a filter to deactivate that requirement, once they are able to put in code, that shows a level of tech competency whereby we can take off the training wheels)

      I have the experience of getting to WCUS, trying to login Facebook only to find it disabled because me being in another country. My backup phone number was unfortunately not one that had roaming enabled. Facebook wanted my photo ID and other really intimate details that I had no intention to give so I gave up and logged in when I returned.

      Users should always have the choice to select the providers that they are comfortable with.

      And do remember though, admins must also have to be comfortable to support 2FA. Normal subscriber roles on websites shouldn’t be able to enable 2FA if the admins don’t even know what it is or at least how it works on WordPress. Administrators should definitely be given the master button like how it is implemented by Google Apps.

    • Doug Smith 3:33 pm on December 12, 2015 Permalink | Log in to Reply

      The regular username / password login can be reset by e-mail as a fallback. A major use case for a second factor is to protect against something like a compromised e-mail account being used to reset logins. Doesn’t using the same fallback for factors then effectively remove the second factor?

    • Michael Arestad 8:53 pm on December 12, 2015 Permalink | Log in to Reply

      I’m still very much on the fence with this being in core from a user experience standpoint. I’m really worried about people locking themselves out one way or another. I’m worried about the ease of use. I’m worried about users avoiding it altogether.

      If it feels really nice to use and isn’t presenting people with tons of settings (kinda like Slack’s email login, but that’s probably more like 1fa), then I’d be more comfortable with it.

      If it’s something that only a very few will use, I would prefer it not be in core. My gut feeling is that adoption of it would be low for a few reasons:
      1. 2fa can be pretty confusing.
      2. It requires some aspect of app switching (to check email/text/etc) to do it. If it’s pretty dang tedious to do and makes you think, why do it?
      3. They have never used it before, so why use it now?

      I want to see where this ends up before I weigh in either way, though. I think it’s definitely needed, but maybe not wanted by the majority of users. I like @kraftbj‘s suggestion of at the very least maybe providing the infrastructure in core (if needed) for 2fa plugins.

    • thetechnuttyuk 1:37 pm on January 25, 2016 Permalink | Log in to Reply

      I noticed this today, so sorry I’m a bit late to the party, I just need to mention my thoughts on WordPress integrating 2FA directly into WordPress, as I have a problem with it.

      That problem is that generally WordPress likes to add features without a turn-off switch, srcset was a recent example of that. 2FA would need to have a turn off switch, that completely turns it off, not just kinda turns it off, completely turns it off, not only because not everyone wants to use it, but because some people want to use software that is better than what WordPress is likely going to integrate, Duo Security being the perfect example of that.

      For that reason, I believe it’s better to simply keep this feature as a plugin addition, maybe ask the user if they want to add it via something like Jetpack, or just showing a message in Core, but honestly, this should not be a built-in feature that has no option for turning off, without adding code in files you’ll forget about and replace a year later.

  • George Stephanis 2:31 pm on August 31, 2015 Permalink
    Tags: , ,   

    Two-Factor Auth Update 

    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 PHP 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 plugin 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.

    Please, test and report both errors and suggestions either on GitHub or on our Slack channel — #core-passwords.

    As always, our next chat will be on Thursday at 5pm Eastern, in #core-passwords.

     
    • JeanPaulH 2:58 pm on August 31, 2015 Permalink | Log in to Reply

      We’d love to have application password support, so please keep supporting this.

    • Aaron D. Campbell 3:18 pm on August 31, 2015 Permalink | Log in to Reply

      I think app passwords are important. I’m honestly wondering though if they shouldn’t basically be another provider (thus making them something that can be turned off rather than just not used).

      As for QR codes, I can definitely see the merits of both the JS and PHP methods. I still have a hard time breaking myself out of the old school rut of “don’t rely on JS”. It seems like using a PHP library would allow you to still function without JS while still using JS to augment and enhance the functionality (like regenerating the QR code via an httprequest.

      Having said that, the JS library I’ve used for this before was https://github.com/jeromeetienne/jquery-qrcode/ (also MIT). It still works well, but it looks like it hasn’t seen any love in the last year.

      • George Stephanis 3:15 pm on September 2, 2015 Permalink | Log in to Reply

        The jQuery QRCode library you linked actually just uses the one that I linked — https://github.com/jeromeetienne/jquery-qrcode/blob/master/src/qrcode.js — to generate the image itself. (like I said, it seems to be the de facto standard)

        I don’t think application passwords can be just another provider — as they aren’t used in the same way. They’re not used as the second step, and only work on non-interactive logins. That is, if someone has an Application Password, they should only be able to use it for xmlrpc or the like — not actually logging in to the admin panel as you.

  • George Stephanis 12:10 pm on August 3, 2015 Permalink
    Tags: , ,   

    Two-Factor Authentication Weekly Update! 

    We met on Thursday and discussed the providers in progress — TOTP, FIDO U2F, and Backup Codes.

    https://wordpress.slack.com/archives/core-passwords/p1438290019000492

    In Attendance:

    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! 🙂

    Next meeting will be Thursday, August 6th at 21:00 UTC

     
  • George Stephanis 12:09 pm on July 24, 2015 Permalink
    Tags: , ,   

    Two Factor Meeting Recap 

    Next week’s meeting will be on July 30th, 2015 at 17:00 ET — two hours later than this week’s meeting, to try and not drop it at 4am for some of our people.

    Log: https://wordpress.slack.com/archives/core-passwords/p1437678027000327

    Folks in attendance:

    @georgestephanis
    @bjornjohansen
    @swissspidy
    @stevenkword
    @aaroncampbell
    @jeffmatson
    @extendwings
    @cconover
    @julien731
    @deltafactory
    @tomdxw
    @valendesigns

    Reviewed rough plans with authentication provider classes and who is working on each. @julien731 has a wealth of experience with TOTP and @extendwings with U2F, and will likely be helping with each respectively.

    I’m expecting to have the fallback methods branch finished and merged in by EOD today or tomorrow. At that point, it will likely need some design love, as it will need to account for three different things — what the user’s primary provider is, what providers the user has enabled, and configuring providers. For the moment we’re going for functionality over design, so it’ll just be checkboxes for available, radio button for primary, and letting each provider handle configuration.

    Added @valendesigns and @stevenkword as committers on the repo.

     
    • CotswoldPhoto 6:39 pm on July 24, 2015 Permalink | Log in to Reply

      I am hoping to use the Google one (I currently use the one written by Henrick Schack together with the Per User Prompt written by Ian Dunn), so I hope it has a lazy code option (allow codes +/- time error) as the time window on the standard version is too tight for many servers to be accurate to. Also, for security reasons, I hope the system uses a per user prompt; the standard WP login box at first, if user and pw are correct, a new box appears to prompt for the 2FA code. Errors returned (to hacking bots) do not reveal that 2FA is active for that user.

  • George Stephanis 3:55 pm on July 21, 2015 Permalink
    Tags: , , ,   

    Two-Factor Authentication — First Weekly Meeting! 

    Our very first first weekly meeting will be July 23rd, 2015 at 15:00 EDT in the #core-passwords channel on Slack.

    We’ll be addressing some varied issues such as:

    • meeting times (is this a good time for everyone? Is earlier/later better?)
    • Two-Factor Providers, who is working on each.
    • Open Issues.
    • Code Reviews.
    • etc.

    As I’m going on Paternity leave in mid-September for a bit, I’m also hoping that over the next few weeks we can collectively find someone else willing to take up the mantle and push Two-Factor forward in my absence.

    For anyone else just new to this, who is wondering what the deuce I’m talking about, Two-Factor is a feature proposal for core to introduce two-factor support in the interest of greater security and paving the cowpaths with a standard api for plugins to extend to provide their own two-factor providers. Active development is currently on GitHub here ==> https://github.com/georgestephanis/two-factor — and I’m happy to add any regular core contributors as contributors on the repo — just ask during our meeting or in the comments below!

     
  • George Stephanis 9:26 pm on January 15, 2014 Permalink
    Tags: ,   

    Due to a lot of stuff in my lap for the next few months, I don’t have the time to keep chasing down things for Search.  If anyone would like to take point, I’d be glad to help in any way possible, I just don’t have the time to wrangle it personally for the foreseeable future.

     
    • utkarshd_42 5:40 pm on March 7, 2014 Permalink | Log in to Reply

      Hi sir,
      I would like to work on the search initiative for the coming GSoC 2014. Can you suggest me as to how to proceed further with the code that has already been completed?
      And what will be my objectives that I have to complete.

      • George Stephanis 5:44 pm on March 7, 2014 Permalink | Log in to Reply

        Have you read the history of posts on this p2 already?

        • Utkarsh Dixit 6:57 pm on March 7, 2014 Permalink | Log in to Reply

          Yes, i’ve already read the entire history of posts. In the ideas page the objectives weren’t specified clearly and i don’t know whether or not you were active on the mailing list, so had to comment here

        • Utkarsh Dixit 7:42 pm on March 7, 2014 Permalink | Log in to Reply

          I’m also going through the codebase of the current plugin available for omnisearch. Hoping to work for the search initiative 🙂

      • Utkarsh Dixit 4:51 am on March 9, 2014 Permalink | Log in to Reply

        Hi sir,
        Can you suggest me some other improvements that you would like to see in the search initiative. Even the ideas that haven’t yet been planned or thought of completely. Hope that I will be able to complete most of them 🙂

      • Utkarsh Dixit 5:50 pm on March 9, 2014 Permalink | Log in to Reply

        Hi sir,
        This includes all the patches I have worked on till now, including the patch for asynchronous search. Please look into it. Its my first time contributing to WordPress so my code might not be upto the par or possible full of bugs. Please suggest changes, approaches, ideas anything that you think might help me.

        https://github.com/utkarshd420/omnisearch-patch/

    • Utkarsh Dixit 5:06 am on March 8, 2014 Permalink | Log in to Reply

      “the biggest task at present seems to be unifying all the search forms in the administrative interface to feed into a global search ”

      We could already use the code given for omni search plugin and could probably change the action parameter of each search form in the admin panel with a hidden input of

      <form id="posts-filter" action="” method=”get”>

      Plugin should be activated for this… Therefore we can use the plugin already build to unify all the search fields in the admin panel..
      is this approach feasible? It works well (I’ve tried for the search posts form)..

    • Utkarsh Dixit 2:18 pm on March 8, 2014 Permalink | Log in to Reply

      I’ve also tweaked the codebase ,of the plugin, a little now it shows the the no. of posts (if found).. Not much a change, but now I have the basic understanding of the way this plugin works.. Waiting for some further updates 🙂

    • Utkarsh Dixit 11:16 am on March 9, 2014 Permalink | Log in to Reply

      Trying to include the suggestions of posts to search in the plugin too, using AJAX to do it… I’ll share the patches one it’s completed. Hoping to complete it soon.

      • George Stephanis 9:56 pm on March 9, 2014 Permalink | Log in to Reply

        Howdy.

        Sorry for the delay getting back to you, just a bit overwhelmed with other stuff this weekend.

        I’ve actually just added you as a committer to the plugin itself — it’s terrific to see someone eager to start working on it.

        I’ll respond in more detail to the above tomorrow! 🙂

      • George Stephanis 9:57 pm on March 9, 2014 Permalink | Log in to Reply

        I would suggest in the interim, though, to read up on Core’s Coding Standards and Styles — things like including spaces, and always using braces for conditionals as an example.

        https://make.wordpress.org/core/handbook/coding-standards/php/

        • Utkarsh Dixit 7:15 pm on March 10, 2014 Permalink | Log in to Reply

          Thanks for the link. Have gone through all the coding standard. Will use them from the next time. 🙂

          Sir, will you be attending this?
          https://make.wordpress.org/core/2014/03/10/gsoc-irc-chats/

          • George Stephanis 9:18 pm on March 10, 2014 Permalink | Log in to Reply

            Yup, I’ll be there. 🙂

            • Utkarsh Dixit 4:49 pm on March 11, 2014 Permalink

              Hi sir,
              Was going across the IRC chat logs when came upon this

              ” often our search acts more like a filter — if I search for “Jaquith” on the posts screen I see a listtable of posts, it doesn’t say what context (or even necessarily what matched if not the title) in the results ”

              I tried making a patch for it… If the search term is in the post or the content of the page it is displayed as

              $title
              …..something something something $search_term something something something….

              In each row.
              I had to tweak the wordpress codebase a little ( WPINC\class-wp-posts-list-table and WPINC\class-wp-list-table)

              Will upload the patch soon and provide the link on this forum 🙂

            • Utkarsh Dixit 6:15 pm on March 11, 2014 Permalink

              There is a slight mistake in the earlier comment I had made changes in wp-admin/includes/ and not in WPINC. Sorry for the above mistake.

    • Utkarsh Dixit 7:09 pm on March 11, 2014 Permalink | Log in to Reply

      https://github.com/utkarshd420/omnisearch-patch

      Also updated the patch I have explained here:
      https://make.wordpress.org/core/2014/01/15/search-initiative-on-hold/#comment-13044

      Hope you will look into it 🙂
      Please provide me feedback, bugs and further approaches you would like the search initiative to have. 🙂

      PS: tried my best to adhere to the coding standards might have some deviations though, as its my first time contributing to WordPress. Hope you don’t mind. 🙂

    • Utkarsh Dixit 7:54 pm on March 12, 2014 Permalink | Log in to Reply

      Hi sir,
      This is in regards with the gsoc chat session.. will you be available between 11:30 am to 8:00 pm UTC, tomorrow i.e. 13/3/2014?
      I would really like to discuss the current patches that I have provided as well as the new approaches that we can take on improving omnisearch.
      Please mention the timings that you will be available at (If you won’t be able to attend during the above time).
      Thanks 🙂

      • George Stephanis 8:07 pm on March 12, 2014 Permalink | Log in to Reply

        Just joined the channel now, I should be online around that span. I may be idling, so feel free to poke me there, or on #wordpress if ever needed — `georgestephanis`

    • Utkarsh Dixit 6:08 pm on March 15, 2014 Permalink | Log in to Reply

      Hi, couldn’t find you on the IRC Channels so am posting here, following (utkarshdixit11.wordpress.com) is the link to my proposal. please go through it once and suggest me any necessary changes that might be needed. Thanks 🙂

  • George Stephanis 4:49 pm on December 9, 2013 Permalink
    Tags: , ,   

    Search Initiative Chat Recap 

    Link: https://irclogs.wordpress.org/chanlog.php?channel=wordpress-core-plugins&day=2013-12-06&sort=asc#m36279

    In Attendance:

    Topics Discussed:

    • The ‘big’ portion of the Search Initiative may have to be delayed unless we get sufficient interest and participation.  A small group with little feedback will have significantly more difficulty building something that will necessarily be attractive to the community at large, and have far less chance of adoption.
    • x-team (Weston and John) have been working on “admin screen search” here, which is very much in line with the Navigation is often tricky to find a menu item (seen time after time in user testing videos). Possibly suggest admin pages as the user is typing their query? auto-suggest item from the original summation post. However, it would need a search field to hook onto to offer the results.  Some questions about how best to cache it were brought up, as that would be expensive to run, but it seemed best to address that after figuring out precisely what it’s going to search and how it’s going to happen.
    • Scott and the Metamorphosis team have been working on how to better structure Post Meta for assorted post types and the like. This would mesh quite well with the Not all relevant information is searched. I may have relevant data stored in a postmeta field, but it’s not indexed for searching item from the original summation post.  If a `include_in_search` flag could be set on specific meta keys, it could provide far more accurate results, as opposed to the status quo, where postmeta is not used in search (leading to rather difficult situations in CPTs where `content` is not supported or is not representative of the item in question)

    We’ll be continuing on December 13 22:00 UTC unless a time that works for more people is suggested in the comments below.

     
    • Scott Kingsley Clark 5:00 pm on December 9, 2013 Permalink | Log in to Reply

      I wonder if exclude_in_search vs include_in_search should be used for interoperability with post type args and the new meta field API we’re working on. What should the default be is the main question here, assume all fields added will get included in searches, or make the default to exclude unless that default is overridden.

      • George Stephanis 5:06 pm on December 9, 2013 Permalink | Log in to Reply

        Possibly instead of having it be a straight boolean, let folks set it explicitly as ‘include’ or ‘exclude’ — and let whatever’s calling them default whichever way it prefers (or to a configurable/filterable value) if not specified?

    • Eric Andrew Lewis 5:34 pm on December 9, 2013 Permalink | Log in to Reply

      Querying post meta data has been a contentious topic. With the current schema and API, querying many meta keys with a search term will not perform well at scale.

      I’ve heard lead developers say that creating complex queries on post meta is doing it wrong (although I can’t find something to cite in that regard), and post meta should exclusively be used for outputting in templates. Although I haven’t heard a top-down recommended alternative to this prickly architectural question. For custom post(/content) types, some projects have invented their own method for dealing with this. BuddyPress uses tables for all of its data objects. Pods creates tables dynamically for custom content types.

      Perhaps a topic to have an IRC summit on, or even its own working group.

    • George Stephanis 1:21 am on December 14, 2013 Permalink | Log in to Reply

      Major apologies, all. I was laid out with a migraine this afternoon and completely lost track of the meeting this afternoon.

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel
Skip to toolbar