[wp-xmlrpc] Any interest in OAuth?

[Allan Odgaard]

On 18 Jun 2008, at 11:40, Joe Cheng wrote:

>> I agree. SSL is the secure way to connect to a server, don’t re- 
>> invent
>> SSL in XML-RPC.
>
> Don't think of it as re-inventing SSL. It's XML-RPC protocols that  
> re-invented HTTP Auth, except in the worst way possible. I just want  
> to negate that epic mistake. :)

I don’t follow this. So XML-RPC did not use HTTP Auth for user  
authentication, instead did their own scheme. And this is an argument  
for them to now also not use the standard HTTP encryption protocol?

> [...] But I'm sure the vast majority of WordPress users don't have  
> access to a cert that's signed by a trusted authority. (Without  
> valid, signed certificates, SSL/TLS is also not fully secure,  
> right?--seems like a man-in-the-middle attacker could easily get the  
> unencrypted password.)

Whoever signed the certificate has nothing to do with the security of  
the connection.

The reason you want a signed certificate is that the _first_ time you  
connect e.g. to example.org then you are presented with a host key and  
you have no guarantee that you are actually connected to the machines  
actually running example.org or instead misdirected to a malicious  
site (posing as example.org).

If the public key offered to you by example.org is signed by e.g.  
VeriSign, your OS will automatically trust that you are connected to  
example.org (they assume VeriSign verified that the owners of the key  
they signed, are the rightful owners of example.org). If the public  
key is _not_ signed by someone your OS trust, it will show you a  
warning. You should however then be able to say that it’s okay, this  
is the right key for the domain, and the OS will remember that (so  
only if it sees a different key offered for that domain, will it throw  
up a warning).

> I also suspect that few if any web hosts are preconfigured for SSL/ 
> TLS, even with self-signed certs.

Maybe not pre-configured when you pick the cheapest shared hosting  
solution, but all the big ones do offer it, and if you run your own  
server (e.g. via virtualization which today is pretty cheap) you can  
even get signed certificates for free where the signing authority’s  
certificate is in Leopard’s list of trusted CA (if you self-sign, you  
can always add your own root certf. to this list).

>> E.g. if you come up with a challenge/response system (to avoid replay
>> attacks) then you can still be the victim of host spoofing / DNS
>> poisoning. So you also need to verify that you are actually talking
>> with the right server.
>
> We're getting out of my depth here, but for most scenarios, is that  
> really going to be a big problem? My main concern here is to prevent  
> a malicious attacker from being able to hack the user's blog.  
> Stopping eavesdropping would be nice but to me is a distant second  
> in terms of importance. I guess you'd need to not only auth with  
> challenge/response but also sign the requests so a man-in-the-middle  
> can't just change the payload.
>
> Sigh... security is hard. But on the other hand, we are currently  
> sending the password in cleartext. At least it can't get any worse,  
> right?

Sending a password in plain text is a problem if someone intercepts  
the traffic.

The scheme where an md5 of password + random bytes (or similar) is  
sent does not reveal the password (so the malicious user will not be  
able to use it to login to the site) but the malicious user can still  
use the XML-RPC interface with the string obtained (replay attack).

The simplest form of challenge/response have the server initially send  
back a reply to the client (when it connects) which contains a string  
that the client must append the password before it does the md5. This  
however requires the server to keep passwords in clear text (like the  
previous scheme). To avoid that, a public/private key scheme can be  
used, where the server has the clients public key. The server then  
sends the client some random bytes and asks the client to sign these  
(with the clients private key), the server can validate the signature  
(with the clients public key).

This scheme is still susceptible, since the client could talk with the  
wrong host, and this malicious host would simply proxy the challenge  
from the real host, and now have a valid response to this challenge.

To avoid that, the server should verify itself to the client, which  
can be done by a similar public/private key challenge/response system  
(the client then has to know the servers public key).

IMO it makes little sense to just make XML-RPC a little safer when it  
is still unsafe. If you are on a network you do not control yourself  
(e.g. public WiFi) having someone direct you to the wrong host (by  
either sending you false DNS responses or being in control of the  
gateway) is really not that much harder than scan your packets for  
passwords (today majority of WiFi networks do use encryption when  
clients talk with the base station, so the most likely attacker is the  
one who owns the base station; this could be a base station setup to  
mimic a more official public gateway).

So the best approach is really; verify the host key and encrypt all  
traffic transparently to the protocol running on top of the encrypted  
connection. There is then no problem whatsoever by having the protocol  
use plain text passwords (and makes for far the simplest  
implementation).

And this is what https offers…