[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 georgestephanis):

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

 Replying to [comment:27 spacedmonkey]:
 > I think it is a massive security issue that allow bad actors to create,
 edit or delete content on a users site.

 I'd like to understand how you think adding this in would introduce a
 **new** concern on that front.  Core already has basic authentication
 enabled via XML-RPC which means all of your concerns apply to what's been
 status quo for core for well over a decade.

 The only relevant difference is that this requires HTTPS, whereas XML-RPC
 can operate over unencrypted HTTP protocols.

 > Without brute force protection in core, it would also bad actors to
 brute force a password. I know this issue with the normal password login
 screen, the rest api allow for a high level of automatication when it
 comes to attacking sites.

 This is arguing for brute force protection in core.  Not really relevant
 to this issue.  If you want to argue for that, maybe reopen #24193?  Folks
 can already brute force requests to wp-login.php and xmlrpc.php -- I'm not
 quite sure why you think it would be easier to brute force a rest api than
 the existing pathways -- but would be delighted to hear your reasoning.

 > How about the following.
 >
 > - Create a new API that allow for password and username to be submitted
 ( requiring SSL ).
 > - This endpoint returns a token ( maybe a JW Token ).

 How would this avoid your concern about brute forcing?  The instant
 someone can pass in a username and password, and tell whether it worked
 (by getting a token back) they know the credentials and can send them
 again to get new tokens at will.

 > - This token would live for the same amount of time as the users cookie
 ( 2 days / 2 weeks ).
 > - Another api could be added to get a refreshed a get a new token.
 > - If a user changes passwords, all tokens will be revoked.
 > - Authicated requests will require the token to sent as a header.
 >
 > There is already a plugin that does this on github called
 [https://github.com/Tmeister/wp-api-jwt-auth Tmeister/wp-api-jwt-auth].

 There are a number of plugins that perform similar token based
 authentication.  I wrote the initial pass of https://github.com/wordpress
 /application-passwords myself, and iirc @valendesigns based some work on
 application-passwords when working on the https://github.com/WP-API/jwt-
 auth plugin.

 Token based authentication has the benefit of being able to individually
 revoke specific tokens, but if an application is ever given your actual
 username and password (as you suggested above), then that makes **any**
 security benefit entirely null and void.  The only way to secure against a
 rogue application that has your real credentials is just to change your
 credentials.  Which, as you also stated that would revoke all tokens,
 what's the benefit over just passing your username and password encrypted
 via HTTPS?

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