Name: drupal-cryptfield
Owner: Makina Corpus
Description: Encrypt field values at the field sql storage level (Drupal 7)
Created: 2018-03-15 17:10:12.0
Updated: 2018-03-15 17:11:00.0
Pushed: 2018-03-15 17:10:59.0
Homepage: null
Size: 7
Language: null
GitHub Committers
| User | Most Recent Commit | # Commits |
|---|
Other Committers
| User | Most Recent Commit | # Commits |
|---|
This is a module for Drupal 7. This module is an alternate field storage engine, using SQL the same way the core field does.
THIS IS AN EXPERIMENTAL PROJECT AND HAS NOT BEEN AUDITED BY SECURITY EXPERTS, YET, USE AT YOUR OWN RISKS!
Download and install this module using composer:
oser require makinacorpus/drupal-cryptfield
If you can't use composer, you must also install the paragonie/sodium_compat
PHP package manually if you are using PHP < 7.2. You can find the source code
and documentation there: https://github.com/paragonie/sodium_compat
Then enable the module:
h en cryptfield
For using the storage engine instead of Drupal core's field_storage_sql own
engine, refer to Drupal core documentation. If you are creating your fields
manually during hook_install() or hook_update_N() execution, you can add
the following data within your field description array:
tion mymodule_install() {
eld_create_field([
'field_name' => 'my_first_encrypted_field',
'type' => 'text_long_with_summary',
// Append this:
'storage' => [
'type' => 'cryptfield',
],
;
As of today, the engine does not support any options at the field level yet (it probably will soon).
You cannot use entity field queries as known as EFQ with this engine.
It makes no sense to index encrypted data: it would leak the data iself
by reading or attacking the indexes.
We are not cryptography experts, if anything in this is wrong, reviews will be gladly welcomed, patches too.
As stated upper, we are not cryptography experts, and we do trust people who
are, Paragonie, which did ported libsodium to PHP
are. If you are using PHP 7.2, libsodium is included into PHP core itself.
Basic secret-key encryption using sodium_secretbox_* is being used, we have
no use in using asymetric private/public key encryption, not until we deal with
user's own need for privacy.
Read more about this topic on Paragonie's documentation site.
A single site-wide private key will be used to encrypt the field values,
nevertheless, to enfore maximum security, each field row in database will
carry its own nonce (sometime called salt or iv), then:
The shared private key itself is stored into a file on disk, per default
it is being stored in private://cryptfield.key.
For maximum security, this key is itself encrypted using another key stored
in configuration under the cryptfield_secretbox_key_key variable:
when deploying a site in production, you should set this variable into
your settings.php file.
The nonce used to decrypt the private key itself is stored in the variables
as well, under the cryptfield_configuration_nonce variable.
If configured correctly (i.e. with the cryptfield_secretbox_key_key variable
into the settings.php, this means that, in order to steal your private key,
an attacker would need to do all of:
Only then, the attacker could decrypt the private key.
Please note I'm not really sure this is useful in the end, but it does work.
Add an option at the field level that allows only a configured user to decrypt field's content: for this, a per-user private key needs to be stored along the user structure.
Create one single table for all fields on the same entity that have a cardinality set to 1 (yes, we do have serious performance problems on some sites).