[wp-trac] [WordPress Trac] #42790: Permit basic authentication to the REST API over SSL

[WordPress Trac]

#42790: Permit basic authentication to the REST API over SSL
-----------------------------------+---------------------------
 Reporter:  kadamwhite             |       Owner:  andraganescu
     Type:  feature request        |      Status:  assigned
 Priority:  high                   |   Milestone:  5.5
Component:  REST API               |     Version:
 Severity:  normal                 |  Resolution:
 Keywords:  2nd-opinion has-patch  |     Focuses:  rest-api
-----------------------------------+---------------------------

Comment (by TimothyBlynJacobs):

 From my experience the fundamental difference between Basic Auth and
 logging in via wp-login.php is that one mechanism can easily have
 additional security protections put in place, and one can't.

 With wp-login.php, it can easily support Recaptcha, Two-Factor,
 Passwordless, SSO, network-based protection ( like Jetpack ) Cloudflare
 and other protections.

 With XML-RPC that is a lot more difficult. Anything interactive like
 Recaptcha, Passwordless or SSO doesn't work because it isn't interactive
 auth.

 Two-Factor can be done, but it is an incredibly painful user experience,
 and pretty much only works with a TOTP type system since you'll typically
 append the 2fa code to the password.

 Adding IP based protection is also much more difficult to impossible if
 you want to integrate with non-browser based applications. Both something
 like Jetpack Protect that is network based, or local to the server using
 fail2ban, etc... Take a hypothetical Zapier app. All the login requests
 will be occurring from the same set of IPs. If a user types in their
 WordPress password to Zapier wrong one too many times, they could lock out
 the entirety of Zapier.

 Cloudflare based protections also are much weaker since it can really only
 be done in [https://support.cloudflare.com/hc/en-us/articles/200504045
 -Using-CloudFlare-with-your-API API mode].

 From our data, we see far more attacks via XML-RPC, and this is with a
 plugin that recommends disabling XML-RPC if possible. It appears that APIs
 are being used and more for credential stuffing attacks:
 https://www.csoonline.com/article/3527858/apis-are-becoming-a-major-
 target-for-credential-stuffing-attacks.html

 ----

 If the only use case we were interested in was that of something like
 MarsEdit where your password would only sit in your machine, I would be
 less worried about all of the above. But there is also the matter of
 giving your password to another service.

 There is the obvious concern that making this the way applications
 interact with your WordPress site will make users more comfortable
 entering their WordPress password into places other than their WordPress
 site. This has clear phishing implications.

 What if the service gets compromised? With OAuth or Application Passwords
 revocation becomes much simpler. Any non-compromised integrations can
 continue to work, but the compromised service key can be revoked. With
 basic auth, you'll need to rotate your actual WP password which would
 involve changing it with _every_ service you've signed up for.
 Additionally, users reuse passwords, a lot. If the service gets
 compromised, we shouldn't add to the damage that compromise can do.

 ----

 > While everything you stated is a totally valid concern, I don't
 understand how it's any different from the status quo?

 I agree that it isn't different than the status quo. But in my opinion,
 the status quo is not great. Since the REST API is how we want 3rd party
 developers to interact with WordPress going forward ( a future GraphQL
 core project could also reuse the wp-api authentication mechanism ), I
 think we have a duty to make the authentication alongside it much more
 sound.

 One of the reasons so many people disable XML-RPC is because of the
 security ramifications, as I outlined above I don't think those concerns
 are unwarranted. If we shipped basic auth for the REST API, I think a
 large number of users would disable it, and we wouldn't have made any
 progress.

 ----

 @andraganescu I think the WP-API team's authentication project is in great
 shape for a merge proposal in 5.6 with plenty of time to spare. If you are
 interested in getting involved: https://github.com/WP-
 API/authentication/projects/2 It follows fairly closely to how
 WooCommerce's authentication flow that seems to work quite well and is
 standards based.

 So from my perspective, we should continue to address the open issues in
 the wp-api/authentication repo and finish our MVP. My goal would be to
 complete a merge proposal by mid-July. If that merge proposal is rejected,
 then taking another look at this basic auth ticket or @georgestephanis's
 app passwords would be what I'd endorse. Chatting in #core-restapi, my and
 @spacedmonkey current preference would be to take this out of the 5.5
 milestone.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/42790#comment:34>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform