Securing wp-admin with SSL - Part 1

[color_box variation="glossy_red" title="DISCLAIMER"] I wrote this quickly and from the top of my head, without doing any verifications. Apologies if I got something wrong! Do not hesitate to point it out and i will fix it. [/color_box]



[dropcap4]W[/dropcap4]ordpress is one of the most used content management platforms available, and as a consequence it is a prime target for attacks and exploits. Unless your site is a target, having a strong admin password and keeping your Wordpress installation up to date is most likely sufficient to avoid being hacked, but there are many additional steps you can take to improve security. Using SSL to access the admin area of your site is one of these.

If you access the admin area of your site over http, your username and password are sent to the server unencrypted when you login. This can be a problem if you are using an unsecured network (any open wi-fi for example), as anybody in the same network could easily intercept your credentials.

Using SSL solves this problems, as all communications between your browser and the server are encrypted.

I have split this topic in two posts. This post gives an introduction to SSL and explains how it all works. The next post (most likely next week) will be a simple and practical tutorial on how to set this all up on your blog.

There are many other steps that are important to achieve basic security on Wordpress, but this is beyond the scope of this post. You can look at the following two links for further information.

  • From Smashing Magazine: [fancy_link target="blank" link="" variation="primary_red"]10 Useful WordPress Security Tweaks[/fancy_link]
  • From the Wordpress Codex: [fancy_link target="blank" link="" variation="primary_red"]FAQ Security[/fancy_link]

Some information on SSL

How it works

Encryption is tricky. Suppose the Internet did not exist, and you had a secret message to deliver securely to a friend. You could lock your message in a box, but then how you send the box key to your friend? If you were sure that the recipient were your friend, a secure way would be the following:

  1. Lock your message in the box (you only have the key of the lock);
  2. Send the box to your friend;
  3. Your friend adds another lock, of which he has the only key, and sends the box back to you;
  4. You remove your lock and send the box a last time to yourfriend.

This sounds time consuming, but it is actually what happens over the Internet, with some additional steps to verify the recipient’s identity. This additional steps require a third party, who has signed the server’s certificate, and who is already known to the client: the Certification Authority (CA).

About Keys

It is important to take a step back and think about keys. It is common conception that when something is locked with one key, you need the same thing to unlock it. This is true in the physical world, and it is also true when talking about encryption, but in the latter case there is more. When you use the same key to encrypt and decrypt data, you are using Symmetric Encryption. This is very strong, but it is useful only if you can transfer the unique key in a secure way, or if you do not need to transfer it at all. What really changed things in the world of data security is Asymmetric Encryption, also known as Public-key Cryptography. With this technology you have two keys: what you encrypt with one, you can only decrypt with the other. In Public-keys Cryptography, we call one of these keys "Private", and the other "Public"; the key concept to understand here is that whatever is encrypted with one of these keys, cannot be decrypted using the same key, but only the other one. This allows us to achieve two very important goals:

  • Secure encryption: If I need to send you some private information, I only need to have your public key. Once I encrypt the message with your public key, I know that only you will be able to read it (obviously all this relies on a private key to remain private);
  • Signature: I am now able to sign data, to prove that they come from me. Let's suppose I need to send you a message: I will send you the message in clear text, and a copy of it encrypted with my private key (what happens in reality is that I only encrypt a unique hash of the message, and not the entire message, but the concept is exactly the same). Only I can encrypt with my private key, but everybody who has my public key will be able to decrypt this copy and compare it with the original message; if the two are equal then only I can be the author. The only advantage of adding the message in clear text is that the recipients can read it even if they cannot decrypt and verify the signature.

These two techniques can be used jointly, so I can encrypt a message, and also sign it: for this I need my private key, and the recipient's public key.

I won't go into the complexity of distributing public keys, and make sure that they really belong to the people they are supposed to. This is why you have the "Web of Trust" networks.

About Certificates

A public key certificate is another way of distributing public keys safely. In better words, a certificate associates a public key with an identity. It is actually quite simple: a certificate contains one's public key signed with the private key of a known third party (the CA). You are supposed to already have a secure way to validate the CA's signature (i.e. I have their public key, more on this later), so when I send you a signed message I can include my certificate (including my public key) along with the message.

The Certification Authority

There are some CA whose public key is already included in your browser; let’s call these Trusted CA. If your browser receives a certificate signed by a trusted CA, it can verify the identity of the server. There are different levels of trust, depending on what verifications the CA does on the certified domain. A class 1 certificate (which you can obtain for free, as I will show you in later) means that the CA has only checked that you control the domain. Technically, for the simple purpose of securing the access to wp-admin, you could be your own CA, create and sign your own certificate. The only drawback is that your browser does not contain your public key, and would give you a warning about this; you can ignore this warning and all communication with your admin area would be fully encrypted. If you always use the same computer and browsers it is safe to add an exception and proceed this way. If, on the other hand, you use multiple browsers on many computers, it is safer to get a trusted certificate, to avoid ignoring a real warning (the untrusted certificate could very well not be yours but some hacker’s trying to get access to your website).


To the best of my knowledge there is only one CA providing free class 1 certificates: StartCom. The reasoning behind this decision is simple: the company claims that the simple verifications behind a class 1 certificate can be fully automated and do not involve human intervention, thus they can provide the service for free. They also provide other services like class 2 and class 3 certificates (implying a verification of your or your company’s identity, in addition to the control of a domain), and Extended Validation (EV: if you have gone through EV, your browser will show a green address bar).

[info_box]This is all for now. The next post will be a step-by-step tutorial on how to practically obtain a class 1 certificate from StartCom, and how to make sure all accesses to the admin area of your self-hosted Wordpress website are secure. Or maybe a screencast.[/info_box]