As you may have read, 23press is going to be building a backup product.  As part of this, obviously we’ve been looking at what other companies do; most importantly, we’ve focused on the two biggest players: BackupBuddy and VaultPress.  Please consider this my disclosure: we are building a competing product.

There are three parts of a user’s WordPress blog that need to be backed up for them to be able to easily plug and play:

  1. User files: this includes theme and plug-in files.
  2. Content: the content of the site: posts, categories, tags, media, plug-in settings, etc.
  3. WordPress core files: the actual WordPress files and any other files generated by/used by WP (including .htaccess and configuration files).

The more I thought about #3, the more I realized what a huge potential security that might be.

I brought the issue to the other founders of 23press: whether or not we backup a customer’s wp-config.php file.  I realized that if we backed up that file and we were compromised, every blog that was backed up to us would be compromised.  Attackers would have the username, password, and hostname for all of our customers’ databases, but worse, would have the salt necessary to decrypt the passwords in the user’s database.

Naturally, we went through the other alternatives in which we could keep the file: we could encrypt it, but where would we store the keys?  We could take the useful information out but where would we store that?  In the database?  In a separate file?  We have to assume that if someone has gained access to our servers, that they have access to wherever the keys might also be kept.

So we made the call that a user should be responsible for their own wp-config.php file.  But what do the other guys do?

VaultPress – Backs up all files, wp-config.php included.  They make note of this on their restoration page (below):

BackupBuddy – backs up everything, wp-config.php file included.  However, the responsibility is passed on to the user to safeguard their data; their file remains with them (man in the middle attacks aside).

With BackupPress, we wanted to find something in between: the responsibility of storing the data should be ours so we can keep it simple, but we do not want to put all of our customers in jeopardy if we were somehow compromised.  After brainstorming with the other founders, we decided that we will back-up everything except the wp-config.php file.  That file, we will have the user download and store.  We will check the file for changes locally; if we see that the file has changed, we will alert the user to re-download and store it in a safe place.  Worst case, if that file is lost, then the user will need to re-enter their database information and reset the passwords for their blog’s users.

As developers, we’re constantly fighting between ease of use and security.  BackupBuddy has gone one way: you control your data, but at the sacrifice of ease of use.  VaultPress has tried to take the other tact: we backup everything for you, but at the potential cost of their users’ security.

Our mission as a company at 23press is to keep things as simple as possible, as often as possible.  But sometimes we need to take security and privacy into consideration.  We think we’ve found a pretty good balance.

What do you think?


2 Responses to The (In)Security of WordPress Backups

  1. Sean says:

    Why not make it so you can’t decrypt the data?

    1. Client generates a public private keypair and encrypts the private key with a passphrase.

    2. At the beginning of a backup session, the client generates a session key and encrypts each file with that session key with AES or something like that. The client encrypts the session key with their own public key and sends it along with the file. (It could be a random key per file, or you could choose to flag certain files as needing encryption, up to you)

    To decrypt the file:

    1. Download the encrypted version + encrypted session key from 23press.
    2. Decrypt session key using private key (after decrypting that with the password)
    3. Decrypt file locally.

    All you have to worry about is protecting the key pair. You could store it in a separate storage system that’s isolated, even offline as a backup, or ask the people to save it themselves (or both). If your database gets compromised, the keys should be protected by virtue of the password.

  2. Terry Smith says:

    Yup, all great feedback. Our mantra is that if someone has access they have access to everything (file system, DB, etc.) so really planning for worst-case scenario. However, we are considering a two-factor authentication brought up by Aaron Brazell that would encrypt the wp-config file client side with a user’s password before sending, then decrypt it if they need to restore it.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>