Add Encryption Functions to Core

[discobot]

A differentiation between WP and CP is that CP is business-focused by being an application development platform, not just for blogging. Part of business operation would be to store personal information which may need encryption due to GDPR recommendations or actual enforcement by data privacy laws. This petition suggests to include 2 functions to encrypt and decrypt data ( i.e. wp_encrypt() and wp_decrypt() ) which can be added in the formatting.php file under wp-includes folder.

A sample encryption and decryption function can be accessed at Line 72 onwards at https://github.com/ray-ang/open-nis-patient-care-summary/blob/master/functions.php

---

Read-only archive: Issues · ClassicPress/ClassicPress · GitHub

Author: Raymund

Vote count: 5

Status: open

---

Comments

See also: Encryption in CP/WP · Issue #523 · ClassicPress/ClassicPress · GitHub

~ posted by James Nylen

I am not sure I understand this proposal. Inclusion in core would suggest that these encryption and decryption functions would actually be used by core. But surely it’s not being suggested that all data be encrypted. Which then raises the question of how can core know when to encrypt data, or which data to encrypt.

Perhaps I’ve missed something, but this sounds very much like plugin territory to me.

~ posted by KTS915

I can’t think of any common scenario where doing this in core makes sense; if you want encrypted data-at-rest do it in the database: Data-at-Rest Encryption Overview - MariaDB Knowledge Base

Could you explain some example use cases in detail please?

~ posted by invisnet

The mariadb link describes database layer encryption. It may be good in encrypting database at rest that are not connected to apps or api’s. The petition involves application layer encryption. Even if there is database layer encryption, if there is weakness in the app or api connencted to the database, the database can still be read unencrypted since the app has privilege to read the database.

The wp_encrypt and wp_decrypt functions can be included in or hook the get_metadata and update_metadata functions to store personal data, such as addresses and phone numbers in ecommerce sites.

~ posted by Raymund

You’re asking for something to be added to Core, and I’m trying to establish if there are any common or frequent use cases; I’m not saying there’s never a need for this.

For example, your approach would help in the specific case of an SQL injection attack, assuming the key is not also stored in the database. However, this is only going to happen if people don’t follow best practice and don’t prepare() their queries - SQLi is entirely preventable.

My biggest concern with this is key management. It’s all well and good providing a couple of encryption primitives, but without effective key management it’s going to cause more problems than it solves. For example, putting the key in wp-config.php will mean it ends up in git and pushed somewhere it shouldn’t be; now you need to re-encrypt everything - do we provide a primitive for that too? Or do we just say “key management is your problem”? To me that’s like handing someone a gun and saying “be careful where you point that” - it’s never going to end well.

With a lot of work on key management and future-proof implementation (AES and SHA2 won’t last forever), in time I can see this as a Core Plugin, but for now I think this is definitely plugin territory.

~ posted by invisnet

Developers should use prepared/parameterized statements to prevent SQLi through the code. Even with this, we still hash passwords to prevent access to plaintext in case of a breach. Same can be said to personal info and encryption. With availability of free libraries, such as libsodium and openssl, it will be an aggravating factor if encryption is not applied - at least application layer for databases connected to an app or api.

I agree with you though that key management would be an issue, or choosing which encryption algo to use. I guess WP/CP are suitable platforms for what they were designed for - blogging and basic applications like brochure sites. Relying on them to build apps holding personal info as well as integrating application layer encryption at its core might be a substantial push to what they were not designed for.

~ posted by Raymund

For basic config, the key can be stored in a php file within WP/CP, not inside the database, like what frameworks do, such as Codeigniter or Laravel. If not wp-config.php, maybe a php file related to core plugin.

I may have to change my initial petition to place encryption features from core to core plugin.

~ posted by Raymund

Is there a way to change the name of the petition, or should I create a new petition to place encryption as core plugin, not in core?

~ posted by Raymund

I apologize but I have to vote against my own proposal for encryption mechanisms within CP, core or core plugin. Encryption should not be made available to those who do not know programming or databases. If encryption is done with PHP, the developer should know PHP and should be able to check the database if data was indeed encrypted. E-commerce, e-learning or membership sites who need to encrypt data such as email, fullname, phone or address should approach this using codes and proper knowledge of encryption.

~ posted by Raymund

Raymund: it is common for petitions to start as plugins. If you are interested in doing this then we can set up a repository under ClassicPress Research · GitHub, or you can implement a prototype under a repository of your own.

“Encryption should not be made available to those who do not know programming or databases” - I agree with this, as written, this petition would just include the basic encryption functions, not any kind of UI or any default usage in core functions.

~ posted by James Nylen

Raymund: what you are saying now makes much more sense to me.

~ posted by KTS915

James: I am interested in working with the ClassicPress-research repository for the plugin. I am thinking of just 2 functions and a key, all in just 1 file, no GUI.

~ posted by Raymund

KTS915: invisnet highlighted key aspects why encryption should be done only by those who understand the concept, and would not be wise to be made available to developers who are more into integrating plugins than programming.

~ posted by Raymund

Hi Raymund, I need your GitHub username and I can create a space for this research plugin. You can leave it here, or send it to me via a private message on Slack or the forums.

~ posted by James Nylen

Hi James, sent you private message via Slack. Thanks for considering encryption as a CP research plugin.

~ posted by Raymund

This repository has been created: GitHub - ClassicPress-research/encryption-functions: ClassicPress EXPERIMENTAL plugin: Functions for developers to use to encrypt data at-rest.

~ posted by James Nylen

I added a file to define pass phrase, and the encryption and decryption functions.

~ posted by Raymund

[viktor]

Petitioner decided this is not necessary in GutHub issue:

I apologize but I have to vote against my own proposal for encryption mechanisms within CP, core or core plugin. Encryption should not be made available to those who do not know programming or databases. If encryption is done with PHP, the developer should know PHP and should be able to check the database if data was indeed encrypted. E-commerce, e-learning or membership sites who need to encrypt data such as email, fullname, phone or address should approach this using codes and proper knowledge of encryption.