<p>You might want to re-think/clarify your strategy here. :)</p>

<p>Is it only custom fields you want to encrypt? Or maybe only specific fields (not every custom one).  Encrypting every bit of data (custom field or not) in a database has <a href="https://stackoverflow.com/a/7252046/684">many</a> drawbacks.  And it doesn't make sense in most cases since 99% of the data in a Craft install usually isn't considered sensitive.  i.e. What does it matter if someone that gets access to your database knows the asset ID for <code>cat.jpg</code> is <code>5</code>?</p>

<p>Encryption/decryption requires a key to be stored somewhere, too. Encryption uses that key to encrypt the data and decryption uses it to decrypt the data.  Chances are, if someone has access to your database, then there's a good chance they'll have access to that key as well.  Because if Craft/PHP is the one doing the encryption/decryption, then the code will need to be able to read that key wherever it might be stored.  And if PHP can read the key, then an attacker probably could as well.</p>

<p>The <a href="https://github.com/romainwurtz/SecureField-Craft/blob/master/secureField/fieldTypes/SecureField_SecureFieldType.php#L64" rel="nofollow noreferrer">plugin</a> you linked simply provides a single custom field type that will encrypt any data that is entered into it, but it has a design flaw in that the encryption key is actually stored in the database. So if the database is compromised, then it's trivial to decrypt the data.</p>

<p>MySQL has some <a href="https://serverfault.com/a/538738/232999">native support</a> for encryption/decryption at the field level where you have to pass in a key with those SQL queries, but that would probably need to be done in the context of a Craft plugin that was maintaining its own database tables.</p>

CC BY-SA 3.0
2016-12-01T14:12:53.280Z
The data I'm talking about is sensitive information about personal data and investment profiles (client is a financial institution). They'd like the data their clients provide to be processed as safe as possible.
Jan Van Echelpoel
CC BY-SA 3.0
2016-12-01T21:03:30.590Z
I'd probably go the plugin route then and have some custom field types that support encryption/decryption (either on the PHP side, or the MySQL side).
Brad Bell
CC BY-SA 3.0
2016-11-30T21:47:15.167Z
2016-11-30T21:47:15.167Z
2017-05-23T12:38:53.957Z
Brad Bell
<p>For maximum security I'd like to implement data encryption in Craft CMS for all data stored in the database. So if it gets hacked the data is pretty much useless.</p>

<p>What's a way to accomplish this? Or is there any plugin that takes care of this? I found <a href="https://github.com/romainwurtz/SecureField-Craft" rel="nofollow noreferrer">this</a> one but it hasn't been updated in 3 years and only supports text-fields.</p>

<database>
Data encryption
# Data encryption

(Asked by: username_0 on 2016-11-30)

For maximum security I'd like to implement data encryption in Craft CMS for all data stored in the database. So if it gets hacked the data is pretty much useless.

What's a way to accomplish this? Or is there any plugin that takes care of this? I found [this](https://github.com/romainwurtz/SecureField-Craft) one but it hasn't been updated in 3 years and only supports text-fields.

**Tags:** database

---

## 1 answers

### Answer by username_1 on 2016-11-30. Score: 3

You might want to re-think/clarify your strategy here. :)

Is it only custom fields you want to encrypt? Or maybe only specific fields (not every custom one). Encrypting every bit of data (custom field or not) in a database has [many](https://stackoverflow.com/a/7252046/684) drawbacks. And it doesn't make sense in most cases since 99% of the data in a Craft install usually isn't considered sensitive. i.e. What does it matter if someone that gets access to your database knows the asset ID for `cat.jpg` is `5`?

Encryption/decryption requires a key to be stored somewhere, too. Encryption uses that key to encrypt the data and decryption uses it to decrypt the data. Chances are, if someone has access to your database, then there's a good chance they'll have access to that key as well. Because if Craft/PHP is the one doing the encryption/decryption, then the code will need to be able to read that key wherever it might be stored. And if PHP can read the key, then an attacker probably could as well.

The [plugin](https://github.com/romainwurtz/SecureField-Craft/blob/master/secureField/fieldTypes/SecureField_SecureFieldType.php#L64) you linked simply provides a single custom field type that will encrypt any data that is entered into it, but it has a design flaw in that the encryption key is actually stored in the database. So if the database is compromised, then it's trivial to decrypt the data.

MySQL has some [native support](https://serverfault.com/a/538738/232999) for encryption/decryption at the field level where you have to pass in a key with those SQL queries, but that would probably need to be done in the context of a Craft plugin that was maintaining its own database tables.

> **Comments:**
> **username_0**: The data I'm talking about is sensitive information about personal data and investment profiles (client is a financial institution). They'd like the data their clients provide to be processed as safe as possible.  
> **username_1**: I'd probably go the plugin route then and have some custom field types that support encryption/decryption (either on the PHP side, or the MySQL side).  

---

