Support for storing and getting encrypted options

[vedjain]

This trac ticket is to see if there's any interest in adding support for encrypted options. Essentially, plugins like WooCommerce store a lot of sensitive data that has implications beyond just the site, such as Payment Gateway API Keys, and other integration keys with adjacent systems.

If we had support for encrypted options, that encrypt values from a salt that's stored in a code file such as wp-config, it would add one more hoop for a malicious actor to jump through in case of inadvertent data exposure. That is, a malicious actor would need access to both data as well as code files to decrypt sensitive values.

The API itself could be as simple as get_encrypted_option or set_encrypted_option with a param to migrate an option on the fly. I'd happy to contribute PR/patches towards this, if we consider this feature.

[johnbillion]

Thanks for the ticket @vedjain. Do you have ideas about how best to implement two-way encryption of data? The main stumbling block for such a mechanism is that it needs to be backed by a secret key that's not stored in the database and doesn't change. The security keys and salts in wp-config.php aren't sufficient for this because they can be rotated.

In a tightly-controlled environment it's possible to use environment variables or a secrets management solution for such a key, but this likely isn't applicable to many sites.

​Felix Arntz wrote a good article covering this topic. ​The `Data_Encryption` class in Site Kit by Google is essentially a wrapper for openssl_encrypt() but depends on a fixed constant being set for its secret key. The fact that it falls back to LOGGED_IN_KEY means that there's a risk of data loss because the encrypted data cannot be decrypted if this key changes.

If we were to implement a data encryption mechanism in WordPress it would need to be backed by a secret key that is not subject to change like the current secret key and salts.