Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Storing secrets #38

Open
pljakobs opened this issue Sep 15, 2024 · 3 comments
Open

Storing secrets #38

pljakobs opened this issue Sep 15, 2024 · 3 comments
Labels
enhancement New feature or request

Comments

@pljakobs
Copy link
Contributor

One thing that came to me while driving today is storing secrets (passwords, api keys, cryptographic keys and the like).
There are a few things I can see with those:

  • we may want to be able to mask them in a stream (for example for an open API)
  • we may want to store and / or stream them as encrypted text
  • we may want to have an API function to access them only if authenticated

Being able to store things like keys and passwords and keys in a safe manner might be a most interesting feature, as key handling is cumbersome or insecure today.

I'm not quite sure how we'll safely handle decryption, though. In the end, some root key/password will have to be baked in to the application.

@mikee47
Copy link
Owner

mikee47 commented Sep 15, 2024

I'm sure we could do something with database callbacks... maybe a hook which gets called before data is serialised and another after it's de-serialised. That way the application can manipulate the data any way it sees fit.

@mikee47
Copy link
Owner

mikee47 commented Sep 26, 2024

mask them in a stream (for example for an open API)
store and / or stream them as encrypted text

On principle, sensitive data should remain encrypted until point of use.
That means it's stored encrypted and streamed encrypted.

I'm going to assume therefore that any updates from the client are stored exactly as received.
If the data needs to be manipulated in any way, for example if the streaming and storage encryption schemes differ, then that can be handled post-transaction as discussed in #48.

we may want to have an API function to access them only if authenticated

Reading and writing encrypted properties via the API could be done externally, i.e. the application encrypts the value itself before writing, and decrypts after reading.
In some ways this might be preferable since the application has to give special attention to such values.

Authentication is outside the scope of ConfigDB. See https://sming.readthedocs.io/en/latest/_inc/Sming/Components/IFS/index.html#access-control.
So IFS supports file tagging to support authentication and authorisation, but the application must enforce it.

So doing this via callback would allow encryption/decryption to be transparent to the application, but is that a good thing?

@mikee47 mikee47 added the enhancement New feature or request label Sep 26, 2024
@pljakobs
Copy link
Contributor Author

On principle, sensitive data should remain encrypted until point of use.
That means it's stored encrypted and streamed encrypted.

agreed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants