[wp-xmlrpc] Any interest in OAuth?
m123ixd02 at sneakemail.com
Wed Jun 18 10:36:07 GMT 2008
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-
>> 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 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,
Sending a password in plain text is a problem if someone intercepts
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
And this is what https offers…
More information about the wp-xmlrpc