mikee47 / ConfigDB

Configuration database for Sming
GNU General Public License v3.0
3 stars 1 forks source link

Storing secrets #38

Open pljakobs opened 2 weeks ago

pljakobs commented 2 weeks ago

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:

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 commented 2 weeks ago

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 commented 4 days ago

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?

pljakobs commented 4 days ago

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

agreed.