More Secure Key Storage

[stpaultim]

Description of the need

In a discussion about AI readiness for Backdrop Core it occurred to me that one of the issues I'm dealing with right now is secure API key storage. Many modules already need to need a way to configure API keys. The easiest way to implement this is by adding a configuration option and storing the key in the JSON config file. This is also very insecure and a bad idea, mostly because JSON config files can easily end up in version control. Despite that, at least several contrib projects are doing it already. Not just AI modules, but any module that needs an API key (Github, Trackt-TV, etc).

There is a key module, which provides some support for more secure key storage.

I don't yet have a preferred solution, but am asking the question of whether or not we could provide options in core for more secure API Key Storage. Mostly something that would help/support contrib or custom module developers.

What do you think?

Proposed solution

Not yet sure. Trying to gauge if this is even a good idea and to solicit good ideas for fixing it.

Alternatives that have been considered

The Key module - https://backdropcms.org/project/key

I've been led to believe that we may not want to add this module to core, but might find some inspiration from it.

Additional information

Draft of feature description for Press Release (1 paragraph at most)

Secure storage for API keys is a must have for any modern CMS. Backdrop CMS now provides improved methods for easily securing your API keys needed by custom or contrib projects.

NOTE: I did a quick search for previous issues on this topic and could not find any, which was a bit surprising. If we have other open issues on this topic, let's connect or merge the discussions.

[herbdool]

I've been led to believe that we may not want to add this module to core, but might find some inspiration from it.

Why wouldn't we want to include Key module in core? Or at least the main parts of Key? It does everything we need already:

• It is "pluggable" to have other contrib modules with other providers (look at the long list with the Drupal version of the module https://www.drupal.org/project/key/ecosystem).
• It can be extended to allow storage in environment variables (the latest Drupal version does this).
• The UI is fully functional.
• OpenAI module and other modules already require it.

The module currently depends on plugin_manager, but that can be changed. We've already done that in core. For example, with Views, the CTools plugin_manager was replaced with a Backdrop info-hook-style plugin system. Same with entityreference.

So I don't see any reason to not stick with Key and put all or parts of it in core. No need to reinvent the wheel. Plus this makes it backwards compatible.

[stpaultim]

Why wouldn't we want to include Key module in core? Or at least the main parts of Key?

I heard someone mention that it MIGHT not be appropriate. But, I have no personal opinion of that. If putting key module in wholesale works, wonderful. Thanks for your work cleaning up the key module @herbdool.

This was discussed at a dev meeting, with just a couple of people and there seems to be at least some support for adding this module to core.

[herbdool]

@stpaultim I didn't really clean it up, just small improvements. There was not anything really wrong with it and I don't see what would be holding us back from including most of it in core if people felt the need.

[NormPlum]

I wonder how many people this would benefit.

In Zulip this came up as a result of discussions around AI readiness in core, but it was pointed out that it helps non-AI situations too. AI-arguments aside, who needs this module/functionality in core rather than contrib (where it is already)?

I went looking for how Backdrop handles these decisions and came across the Philosophy page on the Backdrop website (https://backdropcms.org/philosophy).

Mostly something that would help/support contrib or custom module developers.

Backdrop's philosophy seems to say that editors are more valued than developers, and features should benefit the majority.

Is that the case here? (I don't know, hence the question).

[bugfolder]

I support putting support for key storage in core. Yes, a contrib solution exists, but unless someone is thinking about the issue, they won't go looking for the contrib module. Whereas if it's in core, there's a better chance that they'll see it and adopt it (rather than the bad-idea config solution).

[findlabnet]

Is that the case here?

"All animals are equal, but some animals are more equal than others." - George Orwell

[herbdool]

Allowing a site to be more secure has broad benefits, regardless of the role. If anything it helps end users and site builders most of all. For example, if core could make it easier for a module like SMTP to more securely store passwords then that improves the security of the site and the third-party services used. For our clients we usually set the SMTP password in settings.local.php so that it doesn't get saved to config files (or saved to the database if someone is storing config in the db). It also avoids saving the password into a git repo for those storing config there. So I think incorporating some version of more secure key storage in core would meet the threshold of the majority. Meanwhile it's possible for SMTP and other modules to provide some optional Key integration right now.