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

 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. Without brute force protection in
 core, it would also bad actors to brute force a password.

 There is no real security issue in permitting basic auth in core. You're
 sending a username and a password. Since you can do this with both wp-
 login and xml-rpc already, then allowing it in any particular other
 request isn't an issue. The security of allowing such over plaintext
 headers is mitigated by requiring HTTPS (not that we require that for the
 other methods, but still).

 Any possible alternative means of authentication for REST requests would
 have identical security issues. At some point, the user has to login to
 the site, and that means sending it a username and a password. If these
 are being input into say, a phone app which makes REST requests, then the
 security is identical since you're giving the app the password anyway.

 Currently, WordPress uses the "cookie" method. Basically, on login, your
 browser gets a cookie. This cookie serves as a username and password all
 in one. Anybody with that cookie is "logged in" until the cookie expires,
 or the cookie gets revoked (which can be done a number of ways, changing
 the password is one of those ways).

 The "JWToken method" you propose is functionality identical to this cookie
 method. You propose an endpoint which takes username and password, and
 gives the browser a secret code (token) in return. The token can expire,
 it can be refreshed, it can be revoked, all the same things. It's just an
 easier way to get a cookie. However, it is no more secure as the u/pw
 combo must be passed to the endpoint, which means you have to give them to
 the app anyway. The cookie method, in this case, is functionally
 identical.

 A basic auth method is well understood and well documented. It's just a
 header with the username and password in it. Not terribly secure, to be
 sure, but simple, easy to implement, and every platform and library in
 existence can easily support it. It's easy to implement from the WP side
 too, it can be a single function hooked to the "authenticate" filter. It
 is as secure as your password is, which may not be terribly secure, but
 that's more or less the user's problem. It can be brute forced, sure, but
 any method of accepting a password can be brute forced. There's no real
 difference in taking a password via a POST or via a header.

 Other methods to provide authentication can be implemented down the road,
 as needed. But any approach which takes a password from the user is as
 equally insecure as every other approach. One could envision a method
 where the user logs into WordPress themselves, sets up an "application
 password", which they then give to the app in question. This is
 implemented by plugins as well, but it is sort of putting a lot of burden
 on the user to do that. Other approaches like OAuth and similiar will work
 just fine, but these tend to not fit the model precisely, as we're mainly
 concerned with letting users connect programs they are running with their
 own sites, while these models tend to be more of the "letting my
 Facestagram talk to my Instabook account" variety. OAuth and the like let
 users of services have those services talk to one another, not so much let
 them use a program to interact with their own website.

 So, at a basic level, the simple basic authentication is easy to
 implement, drives the line forward, and does not introduce any new
 security issues. Brute force, like it or not, is not a WordPress security
 issue, it is a server configuration issue.

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