Encrypt key value

This is an interesting idea that has been raised before. My inclination is to remove the Configuration key provider from a future version of Key. I can imagine wanting to be able to commit keys (encrypted) in the repo, so that only one key (the encryption key) needs to be stored in a more secure fashion, but can you tell me more about your use case?

Works like a charm, and meets my use case perfectly.

My only point of feedback: why put this in a new module?
Seems like it could be super useful to add directly to key module core plugin set.

The main reason to have it in a separate module, I think, is to be able to avoid having a dependency on Encrypt, if you're not using encryption.

Right, duh, that makes sense.
What about folding this directly into encrypt module then?

That's a really good idea. Can anyone think of a reason this issue should not be moved to Encrypt?

I've thought about this some more and I think we should not move the functionality to Encrypt, since that module is supposed to focus on being an API, without implementing encryption of any specific data. So we could add it to Key, but another option would be to make Key Encrypt its own project.

+1 for keeping it in Key
and +1 vote for RTBC

This works well, very useful. For an extra layer of separation I've overridden the AES key in settings.php so it isn't stored in config files or the database. This can also use environment variables.

$config['key.key.aes_key']['key_provider_settings']['key_value'] = 'XxxxxxxxxxxxxxXXXXXXXXXXXXXXxxXXXxXXxXxXXXX=';

I created a MR with the patch from @pookmish and a small change on the .info.yml file to be compatible with D9

I created a MR with the patch from @pookmish and a small change on the .info.yml file to be compatible with D9

I've tested MR3, and it works perfectly. Would be awesome to have it merged into the stable release.
It's a very useful addition for the key module, I found it very strange that it stored the keys as plain text in config...

I know that it's not best practice to store them in config, but it is possible now, so it makes perfect sense to allow them at least to be stored encrypted.

Any update? Would be great to have this merged... Thanks!

I like the idea of encrypting keys. Here are my thoughts:

• The dependencies would be more cleanly defined if the functionality were provided in a separate project rather than a submodule. It would also limit security issues to that project and would not affect Key. We may even want to expand this functionality to allow key values provided by any key provider to be encrypted.
• The encrypted key value should be base64-encoded, so that it can be better managed in configuration files, and more easily overridden (in settings.php, for instance).
• The key value should be obfuscated when editing the key, so it is never displayed in plaintext in the UI after it's been entered.

I will wait a few days for feedback and then create a new project for this feature and we can address the other bullet points in that project's issue queue.

@pookmish - I don't want to ignore your offer to create the project, so if you're still willing to do it, please go ahead. I think the name you've already given the module, "Key Encrypt", is a good name for it, especially if we end up using it for encrypting key values more broadly, not just in configuration.

I've made a small tweak so the code works for D10.

MR doesn't explicitly support D11

@joseph.olstad, I've updated the core_version_requirement to match the parent module, this adds support for D11.

This MR will not be accepted as described in #24. Instead of updating the MR, a new module should be created.

I did create a module called Key Encrypt, but it's currently empty. Let's bring this work over there.

Adding this work in new module Key Encrypt.
Please refer issue - #3520440: Encrypt key value

Hello @rlhawk, please create branch in key_encrypt project.

Question--why make a new project and not just make this feature a sub module of key?

@japerry see #24

I came across this issue while working on ideas for #3559052: [META] Improve security of AI and VDB provider credential storage. I see that there has not been any recent activity on the Key Encrypt project. Are there any plans to move this forward, or is the expectation that work on Key Encrypt will only resume (or be reconsidered) after Key 2.x is released?