-
-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
Can we use database encryption instead of writing everything as plaintext #4778
Comments
So you have FS-level access-permissions to read the database of the node itsself... How would we write to the database? We would likely have an encryption key lying around somewhere on the same disk I don't see this as being possible or adding security. What is your actual usecase? I think this is a XY-Problem. |
A use case is for example container volumes. When they are detached, plain text passwords remain on the volume or the underlying storage system. The solution in many other projects is to provide an encryption key or seed through env variables or secrets that are not written to disk or into the database. Or consider the case of an exploit enabling an attacker to download the database. It doesn't even have to be a vulnerability in U-K. This is exactly the scenario I was talking about when I mentioned splitting monitoring duties between an internal instance that isn't exposed to the net, but instead 'contributing' to an external instance that's used for simple reachability checks and displaying status pages. |
In v1, the performance budget is too tight to include this. Enabling the SQLite crypto extension https://www.sqlite.org/see/doc/trunk/www/readme.wiki does not seem worth dev-time as I don't think this would help with actual security that much. Think this resolves your request. |
It's unnecessary to encrypt heartbeats and events; but connection strings, authentication headers and such shouldn't be persisted in plaintext, as much as you don't store login passwords in plaintext. There's no performance issue with that either. |
We are not splitting our database. About the performance aspect: |
I didn't say "split the database"; you actually don't even need to change the database at all. Where you save plaintext strings now, you save encrypted bytes - base64 encoded if you prefer. And re MariaDB, that option is mainly targeted at cloud databases with keys managed by the provider or some other means. Even with that enabled, you would still encrypt valuable data yourself. Give me one good reason why my login information to other systems should be stored less secure than my login information to your app. |
See second paragraph here: https://learn.microsoft.com/en-us/azure/mariadb/concepts-security Without a (hardware based) KMS infrastructure in place, MariaDB's encryption at rest features won't be of much help. |
As I read the mariadb docs, this is not the case. From the Microsoft article I don't quite get what you are trying to get at. I don't see why I would trust my environment variables but not the keys managed by my database. Seems like the same level of security to me... |
Think running your own crypto falls under the exponentially harder to test category. |
Every backup will be in cleartext (except for file system based snapshots before you start nitpicking). Every other leak of database connection details will be able to access the data in plaintext. Explain to me why you protect your admin password by hashing it, please. Being the evil advocate and following your logic, I could just say: "there's no need to do that. if someone compromises the app, they can obviously get in without the password. So why bother. And if someone can download the database with the plaintext password, they already have all the data anyway. So why bother." And, yet you hash your passwords.
|
As I said before, I'm no JS programmer. But it's something like this to set you up. const crypto = require('crypto');
const key = crypto.scryptSync(user_supplied_seed, your_chosen_salt, 24);
const iv = crypto.randomBytes(16);
const cipher = crypto.createCipheriv('aes-192-cbc', key, iv);
const decipher = crypto.createDecipheriv('aes-192-cbc', key, iv); |
This comment has been minimized.
This comment has been minimized.
I think the password hashing response is a bad analogy and I am not going to react to that bait. Let's get this discussion back to being productive: So your concern has changed in terms of what the attacker has access to: |
We're running in circles here. Just read my comment you marked as spam. You have two choices:
|
Where do you plan to store the connection string to that secure Maria DB by the way? Answers on a postcard... |
The relevant part of #4784 (comment) which this discussion was missing:
|
Good point. {"type": "sqlite"} or {
"type": "maridb",
"hostname": "localhost",
"port": "3306",
"database": "kuma",
"username": "",
"password": "",
} So in the We have the constraint, that we want to offer simple setup of embedded mariadb. We like our users to have as simple a time configuring us as possible => forcing environment variables is not really something we want. An option to allow for no disk storage of these would be to change the way we handle from writing to disk to staying in the environment variables. uptime-kuma/server/setup-database.js Line 80 in 1100782
This would then allow users to have a encrypted, external mariadb instance which they connect via the credentials in the enviroment variabes and those to never be written to disk. |
This comment was marked as abuse.
This comment was marked as abuse.
This comment was marked as resolved.
This comment was marked as resolved.
You're not just planning to do something which you repeatedly argue against as making no difference - you're even going further and plan to write that information to disk. I'm out of this discussion, but let me give you some points on the way:
about the security aspects of this issue:
|
Most parts of their licence are fine. The only part that is problematic would be |
Re:some performance notes
About the performance problems of While we might have been able to solve it via other ways, this is the way we chose. I don't see us changing out that part as the current push is already nearly done. See #4500 for the bugs left.
Please see #3748 (comment)
The relevant query is currently ( |
We currently don't have a feature where we automatically upload+restore backups to/from a S3 bucket. If we had, that would be encrypted.
Our current project goals are that we are simple to setup and allow great UX. Note Lets be clear on this one: Note Because this might cause an misunderstanding, here are examples what I mean. About the prioritisation:
About the downgrade security aspects of that statement:
And the downgrade privacy aspects:
Easier said than done (at least concearning this issue). I currently don't see good compromises that:
=> For this feature, I currently see it as an either or. Pushing people towards a tool which we don't have to maintain like https://mariadb.com/kb/en/data-at-rest-encryption-overview/ is quite attactive as this gets around the maintenance problem. Assuming we do the change I proposed here #4778 (comment), this should solve the problem of malicious local admins without environemnt variables. You are correct that it does not solve the problem of users sharing database credentials via unsecure means (and the db is publicly routable), but I don't think that this is an attack vector we actually have to protect against. As an analogy: |
This comment was marked as resolved.
This comment was marked as resolved.
Jea, that was likely not the best way to write what I meant and could be misunderstood. Sorry, should not have been this blunt. |
Is this still a release blocker? |
Hi All, Just chiming in as I’ve been watching, waiting and am really looking forward to version 2. The main thing I’m looking forward to is MySQL support, as it addresses a number of requirements for me (performance, size, alternate backup approaches). In general I prefer to keep the WFE and database backend seperate where I can, as there are many advantages. If I’ve read this thread correctly, I don’t think this is a “blocker” for the next release. I can see a lot of debate over effort vs security, and I think it’s important to remember that we have this as a number of people are being very kind with their time. I also already have my own strategies (at an environment level) to address the scenarios being discussed. Unless there are a heap of users saying they really need and/or want this, I don’t think it’s worth holding up the V2 release for it. J |
📑 I have found these related issues/pull requests
No found any
🏷️ Feature Request Type
Other
🔖 Feature description
Database file encryption (Plaintext) in the SQLite to avoid any other users with the same access to watch on IP's logs and others (Using Hash sha-1 like the password of the users)
✔️ Solution
I would love if the plaintext in the database would not be able to read by any standard db browser.
❓ Alternatives
No response
📝 Additional Context
No response
The text was updated successfully, but these errors were encountered: