Drupal is making more and more ground in the enterprise space.
One feature that is commonly requested by corporate IT departments is the ability to encrypt or obfuscate personal information in the database.
This applies to things like name, date of birth, email and other privacy issues, but also applies to things like TFA secrets where inadvertent disclosure via database breach could lead to compromise.
Drupal has always lead the way in security, Drupal 8 is no exception.
Add support for making field API fields encrypted in the database
For PHP 7.2+ we should use the baked in lib-sodium extension (yay for simple and secure encryption baked into php).
For earlier versions we should use defuse/php-encryption v2.x.
The private key would be written to settings.php just like the hash salt - ensuring it isn't kept in the database.
Decide if this is a worthy feature.
Come up with a plan
None
New flag for configurable and base fields to allow developers and site-builders to nominate a field as encrypted.
Fields marked as encrypted will be encrypted before written to the database, and decrypted when loaded from the database.
Comments
Comment #2
ayesh commentedGood idea! This is one thing I was interested for some time, and I will also see if I can help. There is a pure-PHP polyfill for libsodium (https://github.com/paragonie/sodium_compat) that should take use the PECL extension if available. It has not gone through a security audit as far as I know.
Comment #3
cellar door commentedI'm all for supporting and being a part of this effort!
A few things for thought:
The encrypt module (https://www.drupal.org/project/encrypt) already does a great job of creating a pluggable encryption framework with integration with Real AES (https://www.drupal.org/project/real_aes) that may be worth incorporating into this effort.
The key being stored in the settings.php is ok but it's still not good since the db and code are often hand in hand, but creating a pluggable system is best since it gives the community the chance to store their keys as they see fit. Check out our efforts on the Key module (https://www.drupal.org/project/key) to see how we've addressed that.
Lastly there already is a great effort in the Field Encrypt module (https:/www.drupal.org/project/field_encrypt) to do this.
If this gets traction I'd say we take these modules which are already created, vetted and in use and figure out a way to incorporate them. I'd be more than happy to lend any support and/or sponsor the time to make this happen.
Comment #4
cweagansI suggest https://github.com/paragonie/sodium_compat as an alternative to defuse/php-encryption. That way, it's the same API no matter what.
EDIT: I should read the comments before I post. I agree with #1.
Comment #5
mgiffordThis would help with the GDPR stuff.
Comment #6
mgiffordComment #7
dercheffeIMO there should be a new config option in site configuration. Like the private files dir, a new path outside web root for a "key" folder (we should let choose the site builder how to name it, to avoid every site has a similar folder structure, then it's more difficult to hack).
The path to the folder could be stored in settings.php
I would prefer a separate folder structure, because webserver needs permissions to write into private files directory. In the new key directory a webserver should be only able to get reading permissions.
Comment #8
quietone commentedThe core ideas project is deprecated, moving to core. There is a similar core issue,