Using WP salts for custom encryption

Seeing how WP salts can be rotated

It seems like you’ve answered your own question, not a good idea ??

Who are you protecting the data from? If the site owner, you cannot reasonably keep the key on their server anywhere. If only from site visitors, you can keep it on the server, but since sites can be hacked you probably will want to at least obfuscate it so it’s not obviously a security key. Keeping it in one of your plugin’s .php files is probably adequate. If you wanted something more secure you could for example use stenography to hide it within an image file. There are all sorts of techniques for hiding data without resorting to actual encryption.

I am not a security expert, don’t consider my suggestions as best practice.

Yeah, I mean I’m looking for the least effort solution, that’s why I’m thinking about using salts. They are not often rotated in the majority of cases.

I could maybe do some sort of checks like:

$passphrase = defined('PLUGIN_SECURE_PASSPHRASE') ? PLUGIN_SECURE_PASSPHRASE : (defined('SECURE_AUTH_KEY') ? SECURE_AUTH_KEY : 'some random passphrase');

it’s not ideal, but if the constant is set in wp-config.php, that’s the most fail safe solution (but requires user action on the server), then salt (which is not ideal because salts can rotate), and then the passphrase that is set (which is the least secure option, because it’s going to be public).

The thing I’m trying to avoid is users just storing things like secret 3rd party API keys in the database directly, unobfuscated. These keys are used for authenticated calls towards some APIs, so should be kept secret.

And having them stored in the DB as is is a security risk, so I’m trying to minimise that.

I think your security risk link pertains to keeping user passwords in plain text, which should be hashed. Hashing is a one way function, there’s no practical way to discover the plain text from a hash. Encrypting data you need to retrieve is a different situation. While encryption of sensitive data is a good thing, when it comes to automated retrieval the problem becomes where and how the decryption key is maintained.

AFAIK some method of obfuscation is the best you can hope for. But if someone can gain access to the source code that de-obfuscates the encryption key, it’ll be a clear road map on how to decrypt the API key we want to keep secret.

Not being an expert, I think what I would do is go ahead and keep the decryption key in the DB. I might even use an obvious name like “decrypt_key”. However, that value alone will not work to access the API key. It would need further processing to get to a usable key. For example, the saved value would be XORed with some other static string kept elsewhere. The result is then hashed and the hash would be the actual decryption key. Add as many other processing steps as you like. Without the source code, it’ll be virtually impossible for someone to guess at the process needed. Preventing access to the source code becomes the primary security concern. Someone would need server level access and know where to look to find the source code.

Yeah, I mean, I know the difference between hashing and encrption, it’s the obfurscation part that’s bothering me (well the key used for encryption that is).

I’ll try to see how best to implement it, thanks for the advice ????