-
Notifications
You must be signed in to change notification settings - Fork 1
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
Comments
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. |
On principle, sensitive data should remain encrypted until point of use. I'm going to assume therefore that any updates from the client are stored exactly as received.
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. Authentication is outside the scope of ConfigDB. See https://sming.readthedocs.io/en/latest/_inc/Sming/Components/IFS/index.html#access-control. So doing this via callback would allow encryption/decryption to be transparent to the application, but is that a good thing? |
agreed. |
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.
The text was updated successfully, but these errors were encountered: