davideads

ericp, you are completely correct. However, it would seem there are some ways to reduce the risk. Your analysis is based on the ease with which one could intercept the cookies used (unless they have access to the client machine which is storing the cookies, which is a more serious problem). What if you can keep everything on an SSL connection? Ithink that the following solution will work for this, and would appreciate people’s thoughts.

Here’s what I’ve done, which I’ll detail in a howto for implementation details for Apache, probably on the codex. It assumes you have pretty significant powers to configure your webserver.

1) Set up two virtual hosts with the same url (the blog url), one secure, the other not.
2) On the secure virtual host, set up a rewrite rule that shuttles all non-wp-admin traffic to the insecure site.
3) On the insecure virtual host, set up a rewrite rule that shuttles all traffic to wp-admin to the secure host.
4) Put in a filter (via a plugin, attached) that rewrites the links in wp-admin so that once in, all transactions are explicitly sent over an encrypted connection.

What I’m curious about is if with this set of techniques, the cookie or anything else happening in admin goes over an unencrypted connection. I don’t think it does… I added #4 precisely so that packets aren’t sent over an unencrypted connection before mod_rewrite gets a chance to shuttle it over to the encrypted virtual host.

Another step could be to use Apache authentication. What I don’t know about this is what happens with cookies at this point. I think they still get set and are used, but hypothetically they don’t need to be and you could disable the cookie machinery because the browser caches the authentication information itself after the user enters it and sends it with the http headers. Of course, this needs strong encryption end-to-end even more than using the web based login, as the password is being sent in plaintext in the http request lots of times during each session. I don’t honestly think this helps much, except that if the user doesn’t tell their browser to remember the password, it doesn’t persist on their computer, which could reduce the possibility of this information being harvested from the client computer. But that’s a lot of coulds and ifs for the same effective level of security.

Ugh, I’m having trouble posting the code for the url rewriting filter, which I based on the work of Mathias Bynens. Will edit the post soon.