General Data Protection Regulation is activate: 25 May 2018

All personal data needs to be protected.

It would be good if personal data were stored in the database secretly.

The drupal core protects only passwords.

It is good if at least the email address is stored in this way, but it would be good if other fields would allow the encryption to be enabled with a check box.

I think it would be beneficial if this feature was supported by the core of the drupal.

It would be good to have the settings in the settings.php file, such as the e-mail address and even the name's encryption.

Comments

Somfai Tibor created an issue. See original summary.

Somfai Tibor’s picture

Issue summary: View changes
Somfai Tibor’s picture

Issue summary: View changes
cilefen’s picture

Thank you. I think this is a duplicate.

cilefen’s picture

Status: Active » Closed (duplicate)
Somfai Tibor’s picture

Status: Closed (duplicate) » Active

Not Duplicate!
I would like to draw attention to the importance of encryption.

If the fields data is encrypted, you do not have to report the database to the authority!
That is why it is necessary to encrypt sensitive, personal data fields in the database!

The authority also classifies the e-mail address as personal data! But this is definitely necessary for registration!

Currently drupal stores the e-mail address in playn text. That's not right!

In my opinion, it would be beneficial if the possibility of encrypted storage of fields would be supported by the drupal core!

Somfai Tibor’s picture

In today's world, the protection of personal data is becoming increasingly important. So it is important that the personal data fields are encrypted. These fields may vary depending on the specific task. so it would be good to expand the field system with a check box where you can select which fields to be encrypted.

This is not only important for GDPR, but it has drawn attention to the deficiency.

Perhaps the title was unimaginative. That's why I apologize!

Somfai Tibor’s picture

Title: GDPR support » Encrypted storage of fields in core - GDPR support
cilefen’s picture

Ok

cilefen’s picture

Somfai Tibor’s picture

DataBase Email Encryption 2.x:
The required php-encryption directory requires shell access! This is forbidden for many providers!

Not just e-mail personal data!
Personal information may include:

e-mail
Telephone number
MAC Address
IP
Name
Address
GPS coordinates
Car license plate
Photo
Eye color
Leather color
Religion
etc...

That is why I believe that a field encryption service to drupal core would be a benefit to other cms systems.

Everyone can freely tell which fields they want to be encrypted to store, so options are customizable.

On the administration page, you can set the type and strength of the encryption.

mikeohara’s picture

I am going to throw in and Agree with @Somfai Tibor on this one.

Drupal needs to support at rest encryption of field data out-of-the-box. We need to lead not follow. With the nature and volatility of web security right now, combined with stricture and more widespread privacy legislation, we can't avoid this any longer.

I would almost argue that Encryption should be enabled by default. It's important enough.

Somfai Tibor’s picture

Of course, you have to be careful about what is encrypted because the size of the database can be greatly increased. That's why I am the advocate of enclosure. Everyone can define the fields to be encrypted. By default, the email field should be encrypted.

Current Basic Modules:

The basic solution is good. Security of key storage can be enhanced with a variety of keystore services. I think they are not in the core.

mgifford’s picture

Tagging and adding a parent item for Core.

More discussion happening here https://www.drupal.org/project/drupal_gdpr_team

mgifford’s picture

@fgm mentioned this in #2848974-8: Privacy Concerns as GDPR Compliance - "need to encrypt personal data without access to those without a need to know matching the opt-in agreement given"

mgifford’s picture

Also from https://techblog.bozho.net/gdpr-practical-guide-developers/

Encrypt the data at rest – this again depends on the database (some offer table-level encryption), but can also be done on machine-level. E.g. using LUKS. The private key can be stored in your infrastructure, or in some cloud service like AWS KMS.

sam152’s picture

mgifford’s picture

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

code-drupal’s picture

Any update on when this will be available in Drupal core.

It's true that many hosting providers do not provides encryption of db. which is a big concerns for storing Pii data.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

dercheffe’s picture

This is IMO a very very important thing when using Drupal in European market and I would also vote to bring the mentioned modules in #13 into core.

Jonathan Daggerhart wrote a great tutorial series how to encrypt data which can be found here:
https://www.daggerhart.com/how-to-encrypt-field-data-drupal-8/

The only challenge is to find a European GDPR compatible key storage provider. The only solution I found is lockr.io which is is a company located in the US.

dercheffe’s picture

Any news about this issue? How do you solve the data protection of fields with user data?

is there a way to encrypt address field? Doesnt work with field_encrypt module #3119762: Not possible to encrypt address field

Thanks in advance for any help

manuel garcia’s picture

So to anyone that does not know yet, field encrypt module only deals with attached fields (ie fields you can manage via field ui).

The problem lies in encrypting entity base fields, so, those defined by baseFieldDefinitions() on the entity classes, such as Comment's name, mail, hostname, or User's name, mail etc. These to my knowledge there is no contrib solution that can do this.

manuel garcia’s picture

For those that are interested in finding a solution for entity base fields, I have started work on this direction over on #3124467: Support for encrypting entity base fields - please have a look and report your thoughts / findings etc.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

quietone’s picture

Status: Active » Closed (duplicate)