Securing login.php with SSL

I was thinking about setting this up myself, until I thought about it.

The usual problem with this kind of thing is that when you login, you get a cookie. This gets presented to the site for every request we make, so that the site knows who we are. In essence, having the cookie is often as good as knowing the username/password (particularly if the site allows us to enter a new password without requiring the old one).

If you change it so that the login is secure, then this doesnt change; the same cookie the secure login page gave us is used to present ourselves to the site, over a normal (insecure) connection. All we’ve done is stop anyone sniffing our username & password (which, with remember-me style logins isnt something we enter very often anyway). It doesnt stop someone sniffing (and stealing/copying) our cookie and using that to pretend to be us.

I havent looked at the code to confirm this; it’s just something I’ve experienced with other web-based projects I’ve been involved in, and would expect it to apply here. The only way to avoid this, would be to make the entire site run under https.

Anyone else care to comment?

That is not correct.

A cookie does not contain the password. Instead, it contains
a session ID. Once the client has entered his password and
he has been authenticated (via http or https) he then
receives a cookie with the session id.

If someone steals that session id, it won’t do any good since
the server will also check the originating IP address as well.

There are additional security checks as well, like doing a
reverse DNS lookup.

I believe ALL sites should have a secure login. It should also
be wise to make the entire /wp-admin/ browsable only via
https.

If you dont want to pay lots of money for an expensive
certificate, then you can get one for free from:

https://www.cacert.org

Sorry, but in this case I believe you’re wrong.

Actually my theory is not only correct, the situation is worse than I thought. Have you looked at what is inside the wordpress login cookie, or how it’s generated?

Now, I freely admit I’m not a PHP guru, but unless I’ve totally misread the code in wp-login.php, and wp-include/functions/php, then the situation is as follows:

Firstly, there is no such originating-IP check, so stealing the cookie allows the thief to impersonate the owner of the cookie – without even having to do any extra work to spoof IP addresses or anything along those lines.

Secondly, there is no session id as such used to mark that the user is logged in. What actually happens is that WordPress sends back 2 cookies. One contains the username (in plain-text), the other contains the password (double md5-hashed). This doesnt make it possible for someone to discover what that password is, but it is enough for someone else to use that cookie to access the wordpress site as that user, and potentially changing the password.

The problem is, as your comment demonstrates, people seem to think that securing login behind SSL “buys” them safety. It doesnt, unless the whole thing is secure, or other measures are taken (and are proven to be taken, not just assumed).

Anyone else care to comment (with facts this time, please)?

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.

Perhaps you could save your code as a text file on your web server, and then link to it from here? Anyway, I’m interested in knowing what’s going wrong with my lil’ plugin, so keep me updated.

Sorry, have been away for a while …

Certainly, the concept of keeping *everything* on the SSL connection is sound, and by far the easiest solution.

Looking at the approach that you then go on to outline, I’m not sure that it will work, or at least, it’s very prone to breaking, or missing something – including some of these problems:

Firstly, you’ll also need to catch the response to a (successfull) wp-login – this is where the login cookie is first returned to the user, and thus must also be sent over SSL.

Secondly, you’d need to check/modify the domain setting for the cookie to ensure that the client browser knows to only send it for requests to https://some.wordpress-site.org, and not the http equivalent – otherwise, it can still be intercepted easily as before.

Finally, because you’re no longer sending the cookie to the insecure version of the site, it doesnt know that the user is logged in, and so non-admin facilities are unavailable (including posting comments, editting, etc).

So, as I said, it’s much simpler to just deploy wordpress on an SSL-only host, if security is that important.

A simple, additional safeguard is to have a second user account, that has the minimum security level for day-to-day tasks, and only use the admin login where absolutely necessary.

I like the idea of the Apache authentication patch/plugin you mention, I shall have to look into this later. The obvious benefit of this, to me, is that it can share usernames and passwords (and possibly even provide single-sign on behaviour) with existing systems. As you say, it doesnt change the fundamental problem of security, but provides other benefits instead.

See:
https://haris.tv/2007/01/11/wordpress-ssl-plugin-secure-admin-patched-and-working