In this article we’re going to describe a challenge that all WordPress sites face, and outline how we’ve addressed it with our innovative, and secure, File Locker technology.
First, the problem: How can you secure your wp-config.php file against hacking and tampering?
Understanding The Problem Of WP Config File Scanning
ShieldPRO has had a WordPress core file scanner for many years now.
It works by taking “finger prints” of each WordPress Core file, and comparing them against the official files.
If there’s any difference in file contents, then we know that a core file has been modified – and this should never happen.
But there are some important WordPress files that can’t be scanned in this way, namely:
wp-config.phpindex.php.htaccess– not strictly a WP file, and you only have it if you’re hosting with Apache.- Root Web.Config (IIS only)
This is because WordPress doesn’t ship with a wp-config.php file. Instead it has wp-config-sample.php which is renamed to wp-config.php when WordPress is setup and installed.
If we have nothing to compare against, then we can’t scan the file for changes.
It’s a similar story with index.php… this is often modified (legitimately), so we can’t reliably compare it against the official version.
So what options do we have? There are a few, and they all fall under 2 broad types of approaches:
- Store a backup of the file on your site and use it for comparisons.
- Store a backup of the file somewhere else, and use it for comparisons.
The problem with #1 is that you’re duplicating sensitive data and storing it on your site. This basically doubles your chances of sensitive data being breached.
The problem with #2 is that you’re handing over responsibility for storing sensitive data to a 3rd party. This is workable, but far from ideal.
We’ve designed and built a solution that mitigates both of these problems – the ShieldPRO File Locker.
New Feature: WordPress Critical File Locker
Let’s take a bird’s eye view on what ShieldPRO‘s WordPress File Locker system does:
- It stores the backup copy of the critical file on your WordPress site.
- The backup copy of the file is encrypted using an encryption key provided by the ShieldNET API.
- The private key to decrypt the file is not stored on your site – it’s handled by the ShieldNET API.
- The file may be decrypted on-demand, as-needed (and never stored anywhere) using the ShieldNET API.
This approach strikes a balance between the 2 options outlined above. Some admins may still have concerns about this approach, which we’ll address a bit later on.
How ShieldPRO‘s WordPress File Locker System Works
The following is a brief outline to how ShieldPRO‘s WordPress File Locker system works:
- ShieldPRO scans your installation for your
index.php,wp-config.phpand.htaccessfiles in your top-level WordPress installation directory. - For any files that are found, the ShieldPRO plugin will request an OpenSSL Public Key from the ShieldNET API.
- If a public key is obtained from the API, Shield (on your site) makes a copy of the file contents and encrypts them using the public key, and stores it in your WordPress database.
- ShieldPRO will monitor these files and if they’re modified, or deleted, you’ll be alerted.
- You can then view the precise changes from within the Shield Scan section and compare them line-by-line.
- Once you’ve decided whether these changes are good, or bad, you can then accept the changes, or restore the file to its original state.
There’s an important principle to understand in Steps 5 and 6.
In order to review the line-by-line changes, or restore the file, ShieldPRO needs to decrypt the file contents (encrypted from step 3). The only way to decrypt the contents is with the OpenSSL private key.
We don’t, of course, make our ShieldNET API private keys publicly available. So the only way to decrypt the contents is to send the encrypted contents to our API, which will run the decryption and return the contents to your site.
You may have reservations about this, which we’ll address below:
Q: Is it secure that I’m sending wp-config contents to ShieldNET API?
Yes. For 2 reasons:
- The request to the API always uses HTTPS meaning that the data is secure in-transit.
- Your site only sends encrypted data and only when it needs to be read. Your site never sends your raw wp-config contents.
Q: Can we (ShieldNET API) “see” the file contents?
Yes. When your site sends us your encrypted file contents for decryption, at the point where we decrypt the data and send it back to your site, we could read the information. We don’t log it, or save it anywhere.
But why on earth would we? We’re not interested in doing this and could’ve done it long ago. Our service to our customers is solely to facilitate your site security.
Whether you’re comfortable with this, or not, is entirely your choice to make as the site admin, and you can disable this feature at any time.
Q: Could someone else request the contents of the file from our API?
No.
To make it very clear – we don’t store your wp-config file content. We only store the private key that is used to decrypt the data when you need it.
In order to provide your site with the original wp-config file contents, we need your site to supply the original, encrypted data. We can’t recreate your wp-config file from nothing.
Furthermore, all requests to decrypt the data involve a “secret handshake” – we make a call back to your site to verify that you did in-fact make this request. If this fails, we don’t decrypt the data.
The File Locker system is built as secure as it can be. Your site stores the original wp-config.php content securely on your WordPress site without fear that it can be read by anyone else.
What if you don’t want us to ever be able to see the contents of your wp-config.php files? Simply disable the File Locker feature – it’s never enabled by default.
When You Shouldn’t Or Can’t Use File Locker
This is not a backup service for your wp-config.php file. This can’t be used as backup and restore option for your critical files.
For example, imagine your wp-config.php is deleted. That means your WP site wont run, and any handshaking our API requires in order to decrypt your file contents wont work.
Important: This is not a file backup or disaster recovery service.
Also, another point to remember is that a handshake is required to decrypt a file. This means that if your site has some form of limitation in-place to prevent normal HTTP requests, this will fail. An example of this is an “Under Construction” plugin, or a HTTP Basic Auth Username/Password setup.
Your Comments, Suggestions and Feedback
We understand that some folk will never want to send wp-config file contents anywhere, even to our ShieldNET API, so this isn’t a feature you want to ever use.
Again, this is entirely your choice to make and we respect it.
For those admins who are interested in using the feature, we’re always open to your feedback and suggestions on areas you think could be improved. We’d love to hear your thoughts on this – please leave them in the comments below.
This feature will be released to ShieldPRO 9.0.
Is there a way to encrypt email IDs in the WordPress database? And decrypt them only while required like for example sending password reset notifications?
Shield doesn’t have this functionality.
For encrypting email IDs in the WordPress database, you would need to implement custom code or use a plugin specifically designed for data encryption and decryption. This would involve creating encryption and decryption functions, modifying the database interactions, and securely managing the encryption keys.