The advisory is closed, but I think it is a good question, I make it public to see what other people think.

@Tchebychev is concerning plaintext storage of sensitive information inside the SQLite database like PostgreSQL monitor's password.

But I didn't encrypt them, because I think encrypting them is meaningless, as the encryption key will be in the same data directory. If an attacker can read your SQLite database, they can probably get the encryption key to decrypt the information too.

Unlike user password hashing (one-way hashing), passwords can still be verified after being hashed. But for a PostgreSQL password, Uptime Kuma would have to decrypt it to connect to the PostgreSQL database. That is the difference.

From the advisory:

PoC
I carried out this test in a Pod running on Openshift:
Connection to the uptime kuma Pod terminal
sqlite3 /app/data/kuma.db
select * from monitor;
This command displays this:

From another perspective, a lot of deployment methods like .env, docker-compose.yaml or hardcoded password inside a source code program are also in plain text.

So, I think we need a strong reason why storing a plain text password in a .env file is considered acceptable, but Uptime Kuma is not ok.

I have writtten my take on this one here: #4778 (comment)

In v1, the performance budget is too tight to include this.
In v2, you can use MariaDB and https://mariadb.com/kb/en/data-at-rest-encryption-overview/ to achieve this.
Please see #4500 for the status of said release and what needs to happen before we can publish a beta.

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.
If you have insights of how SQLITE-SEE works and if this is simple to configure/maintain and performant enough (provide a benchmark ^^), we can reopen the issue.

=> lets continue any discussion there

Plese respect my comment from above, lets continue the discussion in #4778

You have closed both this issue and the other as "completed" ¯_(ツ)_/¯

And louislam explicitly wanted to know what other people think.

The advisory is closed, but I think it is a good question, I make it public to see what other people think.

You have closed both this issue and the other as completed

I think I have made my point that

• mariadb offers encryption at rest (thus we don't need to add that if a user uses that storage) and
• how reopening Can we use database encryption instead of writing everything as plaintext #4778 for SQLITE-SSE (looks complicated to me and not knex-compatible, but maybe a database person can help us with this) is somewhat pheasable.

Discussing stuff in two issues simultaneously does not really have a point => lets continue the discussion in #4778
If you really want we can make that into a discussion issue..