Title: ericp's Replies | WordPress.org --- # ericp [ ](https://wordpress.org/support/users/ericp/) * [Profile](https://wordpress.org/support/users/ericp/) * [Topics Started](https://wordpress.org/support/users/ericp/topics/) * [Replies Created](https://wordpress.org/support/users/ericp/replies/) * [Reviews Written](https://wordpress.org/support/users/ericp/reviews/) * [Topics Replied To](https://wordpress.org/support/users/ericp/replied-to/) * [Engagements](https://wordpress.org/support/users/ericp/engagements/) * [Favorites](https://wordpress.org/support/users/ericp/favorites/) Search replies: ## Forum Replies Created Viewing 3 replies - 1 through 3 (of 3 total) * Forum: [Everything else WordPress](https://wordpress.org/support/forum/miscellaneous/) In reply to: [Securing login.php with SSL](https://wordpress.org/support/topic/securing-loginphp-with-ssl/) * [ericp](https://wordpress.org/support/users/ericp/) * (@ericp) * [21 years, 2 months ago](https://wordpress.org/support/topic/securing-loginphp-with-ssl/#post-151328) * 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](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. * Forum: [Everything else WordPress](https://wordpress.org/support/forum/miscellaneous/) In reply to: [Securing login.php with SSL](https://wordpress.org/support/topic/securing-loginphp-with-ssl/) * [ericp](https://wordpress.org/support/users/ericp/) * (@ericp) * [21 years, 4 months ago](https://wordpress.org/support/topic/securing-loginphp-with-ssl/#post-151258) * 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)? * Forum: [Everything else WordPress](https://wordpress.org/support/forum/miscellaneous/) In reply to: [Securing login.php with SSL](https://wordpress.org/support/topic/securing-loginphp-with-ssl/) * [ericp](https://wordpress.org/support/users/ericp/) * (@ericp) * [21 years, 4 months ago](https://wordpress.org/support/topic/securing-loginphp-with-ssl/#post-151255) * 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? Viewing 3 replies - 1 through 3 (of 3 total)