One of the common concerns I kept bumping up against was how to collect sensitive information from clients securely. For me, more often than not, it was for one of two main reasons. One was getting credit card information (if they weren't comfortable providing that info over the phone). The other was when taking on new Care Plan clients whose site I hadn't built (requiring me to request things like host and site login credentials for an audit).
In both of those cases, I don't want the client to email such details to me, simply because there are so many points on that email's journey where that data could be compromised - especially because everything is in plain clear text. So that was a big no-no.
In the past, I have used services like NoteShred which allowed me to pass on sensitive information knowing it gets auto destroyed after being read once. The issue for me there is, whilst the "note" is password-protected, communicating that password (to allow the recipient to open the note) requires being communicated to them in some other way (email, chat, text, phone etc). Overall, whilst a lot more secure than just email, it still made me a little uncomfortable.
Most agencies like mine face this challenge. Yes, I know there are numerous paid-for services/plugins that can address this. However, for me, I couldn't shake off knowing that there must be a better way of doing this using my own WordPress site to handle this.
Now, I use Formidable Forms (FF) as my form builder of choice, and forms built with this are the main way I get any information (sensitive or otherwise) from visitors and clients. So surely I could create forms for those two use cases?
The answer is of course - easily. The challenge is that FF saves the collected information to the WordPress database in plain text (as do all form builders, I believe). Sure, this is more secure than sending sensitive data around in emails. However, if my site should get hacked/compromised then all that golden information is easily readable. So that's not good.
So I went on a Google hunt; surely someone else must have done this. It took quite a while (lots of blind alleys and rabbit holes) but I stumbled on a great post by Victor Font addressing this very issue. All the key points I needed were there (so, a very big thank you, Victor, for writing that post).
This post here is very much built on the foundations of that post. So why write another post on this? Well, whilst Victor's post pointed me in all the right places, it still took me a while to implement it and get it all working. So I wanted to go a little further and fill in some of the blanks I had to figure out for myself. If you want to check out Victor's post you can find it here.
So, the purpose of this post is to show you everything you need to do so you can collect that sensitive information through a form, and then encrypt it before writing it to the WordPress database (and, of course, decrypt it after). So if you did, unfortunately, get hacked - at least your clients' sensitive data is not compromised.
Whilst this post specifically focuses on Formidable Forms, the theory and principals should also work for the other big form builders out there like Gravity Forms, NinjaForms etc. Naturally, any equivalent hooks will differ and the suggested code would need to be re-jigged.
I don't believe (at the time of writing) that any of these form builders offer the ability to encrypt field data natively. That said, and not sure how true this is, but I gather this is on FF's roadmap at some future time (no idea when), but until then...
Before we get started:
In order for this to be set up and working, there are few dependencies that need to be in place:
The first thing we need to do is make a change to wp-config.php.
Before that, a couple of points regarding wp-config.php. Usually, by default, this key file is in the root folder of your site. The downside to this is if your site is hacked, then any information in there is compromised, such as database user name and password, plus other stuff like that. To mitigate this you should consider moving that file up a level so it's not in the root folder of your site (i.e. it's no longer a publicly accessible file). This means someone would have to hack your host to get to that file. Whilst not impossible, it's a much harder proposition for a hacker. I use Gridpane to host many of my sites, and by default, they already have it set that wp-config.php is outside the site's root folder.
Now, you cannot simply move the file; WordPress needs to know where it resides. Remember, you don't have to do this, but if you wish to, this article describes how to do just that. If you do move it, remember to update any backup plugin so it knows where that file is now.
Wherever your wp-config.php file resides, the first thing is to define some constants in there. Calls to OpenSSL, later on, will use these. The following sample lines should be added somewhere in your wp-config.php file.
define('FORMIDABLE_SALT', 'bzD?Vi&+s!i{PjUCN2N_+gUQ:`|wt::O/+~!es[pRi%-<JPS<8*Eu1%}R(nmdqY2');
define('FORMIDABLE_METHOD', 'AES-256-CBC');
define('FORMIDABLE_OPTIONS', 0);
define('FORMIDABLE_IV', '!MJekYW9G^6juRBH');Code language: PHP (php)These lines basically define 4 "constants". The last one, for example, defines a constant with the name of FORMIDABLE_IV to have a value of "!MJekYW9G^6juRBH". Essentially, this definition acts like a global variable, except the value cannot be changed, hence why it is known as a "constant". This will save us having to state these values in multiple places. We define them in wp-config.php once, and then reference those constants whenever they're required in OpenSSL function calls.
NOTE: You will need to replace the values for FORMIDABLE_SALT and FORMIDABLE_IV with your own values. This is quite easy to do - and I'll show you how shortly, but first, let's just look at OpenSSL and what these constants are actually going to be used for.
As mentioned earlier we will be using OpenSSL to do the actual encryption/decryption. This is done by calling the openssl_encrypt() and openssl_decrypt() functions respectively.
A call to either looks like:
openssl_encrypt( $data, $method, $key, $options, $iv ); // to ENCRYPT something
openssl_decrypt( $data, $method, $key, $options, $iv ); // to DECRYPT somethingCode language: PHP (php)As you can see, both calls require the same parameters. When we call these functions later on, we will be using our constants for these parameters (except for $data). So what do they mean?
As mentioned earlier, the list of 4 constant defines earlier is just an example. Lines 2 and 3 are fine as is, however you will need to replace the values for FORMIDABLE_SALT and FORMIDABLE_IV with your own values.
For FORMIDABLE_SALT, the easiest way is to visit https://api.wordpress.org/secret-key/1.1/salt/ and copy any one of the generated result values.
For FORMIDABLE_IV, use your favourite password generator to generate a 16-character string.
Once your constants have been added to your wp-config.php file ensure you make a secure copy of those details somewhere else where you'll never lose them. They are required for both encrypting and decrypting. If you lose them you will NOT be able to decrypt any data that was encrypted that used those keys. You have been warned!
The final piece of the puzzle is made up of 5 small functions. These should all be added to your functions.php file (preferably within a child theme).
The first 2 functions are the basic encrypt/decrypt functions. These will be called by the main functions (further down) as required to do the actual encrypting or decrypting, and as you can see they make use of the constants we defined earlier. Essentially, the first takes in data and returns an encrypted version of that data. The second takes in encrypted data and returns a decrypted version of that text.
/* Functions allowing Formidable functions to encrypt/decrypt field data in the database
* - constants/salts are set in wp-config.php
*/
function adz_encrypt( $data ) {
$key = FORMIDABLE_SALT;
$method = FORMIDABLE_METHOD;
$options = FORMIDABLE_OPTIONS;
$iv = FORMIDABLE_IV;
return openssl_encrypt( $data, $method, $key, $options, $iv );
}
function adz_decrypt( $encrypted ) {
$key = FORMIDABLE_SALT;
$method = FORMIDABLE_METHOD;
$options = FORMIDABLE_OPTIONS;
$iv = FORMIDABLE_IV;
return openssl_decrypt( $encrypted, $method, $key, $options, $iv );
}Code language: PHP (php)With the constants defined and the basic encrypt/decrypt functions in place, how do we integrate that with a Formidable Forms form?
Below is an example Formidable Form highlighting the fields I specifically want encrypted (probably overkill, but hey).
As you know, each form you have built with Formidable Forms has an ID, and each field on that form has its own ID too. You will need to know these and note them down.
Using the form above as an example, let's say the form's ID is 22, and the field IDs I want to be encrypted are 300 to 306 inclusive. The function would look like this:
// Encrypts specific fields on forms 22 and 30
add_filter('frm_pre_create_entry', 'adz_encrypt_my_field');
add_filter('frm_pre_update_entry', 'adz_encrypt_my_field');
function adz_encrypt_my_field($values) {
if ( $values['form_id'] == 22 ) { // change num to your form id
$values['item_meta'][300] = adz_encrypt( $values['item_meta'][300] ); // field
$values['item_meta'][301] = adz_encrypt( $values['item_meta'][301] ); // field
$values['item_meta'][302] = adz_encrypt( $values['item_meta'][302] ); // ...
$values['item_meta'][303] = adz_encrypt( $values['item_meta'][303] );
$values['item_meta'][304] = adz_encrypt( $values['item_meta'][304] );
$values['item_meta'][305] = adz_encrypt( $values['item_meta'][305] );
$values['item_meta'][306] = adz_encrypt( $values['item_meta'][306] );
}
if ( $values['form_id'] == 30 ) { // change num to your form id
$values['item_meta'][400] = adz_encrypt( $values['item_meta'][400] );
$values['item_meta'][401] = adz_encrypt( $values['item_meta'][401] );
}
return $values;
}Code language: PHP (php)You'll also see a second "if" block for a second fictional form (ID 30) to illustrate how to manage multiple forms (that one just supposes 2 fields need encrypting). Just delete or comment out that entire "if" block if not required.
So what's it actually doing? Well, in order to encrypt form data, we need to intercept the data from the form after it has been submitted, but before the resultant entry is written to the database. To do this we can use two Formidable Forms hooks (frm_pre_create_entry and frm_pre_update_entry).
These are both called after a form is submitted and an entry is to be either created or updated - but they're called before any data is written to the database. This allows us to then take that data, encrypt it, and then pass it back to Formidable Forms to then be written to the database.
That's the encryption of fields sorted out. Now to decrypt them.
For this, you only need to know the field IDs. As these are all unique, the form ID is not required. In which case you can just list all the fields, regardless of what form they are associated with.
// Click "Edit" on Card Details or Audit Details form entry to see decrypted values
// (NOTE: just "viewing" an entry won't decrypt it - entry needs to be "edited"),
// Only field IDs needed, not form IDs
add_filter('frm_setup_edit_fields_vars', 'adz_decrypt_my_field', 20, 3);
function adz_decrypt_my_field($values, $field, $args) {
if ( $field->id == 300 or // field
$field->id == 301 or // field
$field->id == 302 or // ...
$field->id == 303 or
$field->id == 304 or
$field->id == 305 or
$field->id == 306 or
$field->id == 400 or
$field->id == 401 ) {
$values['value'] = adz_decrypt( $values['value'] );
}
return $values;
}Code language: PHP (php)This function decrypts the fields listed as and when an entry is EDITED (i.e. decryption does not occur if simply viewed). It does this by using the frm_setup_edit_fields_vars hook to intercept an EDIT of any of the listed fields from the database. When that happens it decrypts the passed value before passing the new decrypted value on to be displayed.
You can (if you wish) set permissions in the Formidable plugin for who can EDIT entries. This is useful if you only want to give that functionality to specific users - meaning those that don't have that permission will just see the "view" version of the entry, which will be the hashed gibberish.
What if you need to decrypt fields, but not through the backend? For example, if you have a front-end Formidable Forms View designed for logged in users, say. Or perhaps to decrypt fields for an email (the latter is not recommended, but again, hey).
This uses frmpro_fields_replace_shortcodes hook which intercepts the data, and if a field's shortcode has the appropriate "decrypt" flag set it will then decrypt that field's before displaying the decrypted information.
// For views or other places that can use Formidable shortcodes, e.g. emailing out an entry etc.
// Just need to add "decrypt=1" to the shortcode
add_filter('frmpro_fields_replace_shortcodes', 'decrypt_my_field_for_view', 10, 4);
function decrypt_my_field_for_view($replace_with, $tag, $atts, $field){
if(isset($atts['decrypt'])){
$encrypted = $replace_with;
$replace_with = adz_decrypt($encrypted);
}
return $replace_with;
}Code language: PHP (php)This will work for wherever you can put a Formidable shortcode. You just need to add “decrypt=1” as a parameter of the shortcode. For example, in a view, to show the decrypted values of 2 fields you’d specify:
<tr>
<td>[177]</td> <!-- This field doesn't require decryption -->
<td>[178 decrypt=1]</td> <!-- This field does -->
<td>[181 decrypt=1]</td> <!-- This field does -->
</tr>Code language: HTML, XML (xml)Armed with the constants and all of those functions you should now be good to go.
One of the rabbit holes I ran down was with password type fields. And given, more often than not, it will likely be passwords you want to encrypt, you'll need to bear this in mind.
A Formidable Forms password field is like most password fields; it hides/masks the text that is typed into it. Fair enough, right? The issue comes when you need to see the decrypted password when editing the resultant entry that has such a field.
When you edit such an entry containing a password field, that field (even after being decrypted) still shows in the backend as masked so you can't read it! This stumped me for a little while. In that scenario, the only way to see the password was to use a tool like phpMyAdmin to find it in the metadata tables in the database, and then hack around decrypting it manually. Well, that sucked; and I certainly didn't want to have to do that every time.
Now, there may be a better way than this, but what I ended up doing to work around that was this.
For every password field in a form, I also created a "paired" hidden text field (usually with a label matching the password field's but with the word "(copy)" at the end) and then set that hidden field's Default Value to equal the field ID of the password field - see below for an example.
Then just ensure you include both fields in all the functions, and then the hidden field's decrypted value will be properly visible/available to you.
This was a lifesaver for me, and I hope this helps you out too. If you have any comments/questions, please do comment below.