[GH-ISSUE #755] use a password to protect the sqlite database.

kerem commented

2026-03-13 11:54:11 +03:00

Owner

Originally created by @goldenbull on GitHub (Nov 6, 2024).
Original GitHub issue: https://github.com/1Remote/1Remote/issues/755

Originally assigned to: @VShawn on GitHub.

I have read the docs discussing why there is no password protection for sqlit database:

https://1remote.org/usage/database/security/

But I think password protection is still necessary. Thinking about a simple scenario: I have several PC/laptops, one in office, one in home, one laptop, etc. I need to use 1remote on all of these machines. To keep the sqlite databases all synchronized among these machines, I need to: 1. copy db file by hand once an connection entry is modified, or 2. use git to sync the db file, and run push/pull on modification, or 3. use some cloud synchronization service, like Baidu YunDisk, Nutshell Disk, One Drive, etc. The last method is the most convenient. But in this case, the usernames and passwords of all my connections are visible to the cloud providers. This is horrible.

Just a simple password protection will eliminate the danger of snooping. And of course, it's an optional function.

Originally created by @goldenbull on GitHub (Nov 6, 2024). Original GitHub issue: https://github.com/1Remote/1Remote/issues/755 Originally assigned to: @VShawn on GitHub. I have read the docs discussing why there is no password protection for sqlit database: https://1remote.org/usage/database/security/ But I think password protection is still necessary. Thinking about a simple scenario: I have several PC/laptops, one in office, one in home, one laptop, etc. I need to use 1remote on all of these machines. To keep the sqlite databases all synchronized among these machines, I need to: 1. copy db file by hand once an connection entry is modified, or 2. use git to sync the db file, and run push/pull on modification, or 3. use some cloud synchronization service, like Baidu YunDisk, Nutshell Disk, One Drive, etc. The last method is the most convenient. But in this case, the usernames and passwords of all my connections are visible to the cloud providers. This is horrible. Just a simple password protection will eliminate the danger of snooping. And of course, it's an optional function.

kerem

2026-03-13 11:54:11 +03:00

closed this issue
added the
meta-feature
label

kerem commented

2026-03-13 11:54:27 +03:00

Author

Owner

@goldenbull commented on GitHub (Nov 6, 2024):

there are two ways to implement the feature:

use some 3rd-party library which support sqlite encryption, like sqlcipher
do not store the the original plain text but the encrypted data into db
seems the second way is much simpler, just need to add an extra encrypt/decrypt operation on read/write db.

There is a third way, use an encrypted XML/JSON file to save all connections, which is also a possible solution.

@goldenbull commented on GitHub (Nov 6, 2024): there are two ways to implement the feature: 1. use some 3rd-party library which support sqlite encryption, like [sqlcipher](https://github.com/sqlcipher/sqlcipher) 2. do not store the the original plain text but the encrypted data into db seems the second way is much simpler, just need to add an extra encrypt/decrypt operation on read/write db. There is a third way, use an encrypted XML/JSON file to save all connections, which is also a possible solution.

kerem commented

2026-03-13 11:54:32 +03:00

Author

Owner

@VShawn commented on GitHub (Nov 7, 2024):

The sensitive data in the 1Remote database has been encrypted for storage. However the exe that downloads from GitHub shares a common encryption salt. So we aimed for users with high security requirements to modify the encryption salt and build the exe themselves. With the self-compiled exe, the passwords in databasse can only be read by your own exe. Even if sync database makes a the db file leak, your sensitive data will still be safe.

Of course, I know it would be better if 1Remote provided a feature that allows users to modify the current encryption salt, but this functionality involves a amount of work, I haven't had enough time for it, so the topic has been put on hold.

The feature involves:

Providing functionality to modify the salt value and alerts for incorrect salt values
How to store the custom encryption salt
- Configuration files in the same directory as the exe
- Configuration files in AppData
- The registry
- Credential Manager
A reminder module to alert users to back up the salt value regularly, as data would be completely lost if the salt value is lost.
Offering clear user guidance in documentation

BTW. full json encryption is not acceptable to me as It took long time if the json text is long.

@VShawn commented on GitHub (Nov 7, 2024): The sensitive data in the 1Remote database has been encrypted for storage. However the exe that downloads from GitHub shares a common encryption salt. So we aimed for users with high security requirements to modify the encryption salt and build the exe themselves. With the self-compiled exe, the passwords in databasse can only be read by your own exe. Even if sync database makes a the db file leak, your sensitive data will still be safe. --- Of course, I know it would be better if 1Remote provided a feature that allows users to modify the current encryption salt, but this functionality involves a amount of work, I haven't had enough time for it, so the topic has been put on hold. The feature involves: 1. Providing functionality to modify the salt value and alerts for incorrect salt values 1. How to store the custom encryption salt - Configuration files in the same directory as the exe - Configuration files in AppData - The registry - Credential Manager 1. A reminder module to alert users to back up the salt value regularly, as data would be completely lost if the salt value is lost. 1. Offering clear user guidance in documentation --- BTW. full json encryption is not acceptable to me as It took long time if the json text is long.

kerem commented

2026-03-13 11:54:37 +03:00

Author

Owner

@goldenbull commented on GitHub (Nov 7, 2024):

In some scenarios, the sensitive data is not only password but also IP address (and other information). For example, a custom vps providing Trajon service to bypass the Internet censorship. In court, the SSH entry with the vps IP in the db file is the evidence of the ownership of the vps 😨

@goldenbull commented on GitHub (Nov 7, 2024): In some scenarios, the sensitive data is not only password but also IP address (and other information). For example, a custom vps providing Trajon service to bypass the Internet censorship. In court, the SSH entry with the vps IP in the db file is the evidence of the ownership of the vps 😨

kerem commented

2026-03-13 11:54:42 +03:00

Author

Owner

@goldenbull commented on GitHub (Nov 7, 2024):

and talking about AES, is salt unnecessary if password is long enough? (like 32 random characters generated by keepass)

@goldenbull commented on GitHub (Nov 7, 2024): and talking about AES, is salt unnecessary if password is long enough? (like 32 random characters generated by keepass)

kerem commented

2026-03-13 11:54:47 +03:00

Author

Owner

@goldenbull commented on GitHub (Nov 7, 2024):

I think the json file performance is acceptable in most situations.

generally there are at most hundreds of connection records
we have a lot of RAM
and a fast CPU. In my test, Aes can encrypt/decrypt 10MB data within 0.1s

@goldenbull commented on GitHub (Nov 7, 2024): I think the json file performance is acceptable in most situations. - generally there are at most hundreds of connection records - we have a lot of RAM - and a fast CPU. In my test, `Aes` can encrypt/decrypt 10MB data within 0.1s

kerem commented

2026-03-13 11:54:52 +03:00

Author

Owner

@goldenbull commented on GitHub (Nov 7, 2024):

I can write a json database with encryption support, if it's not completely objected 😄

@goldenbull commented on GitHub (Nov 7, 2024): I can write a json database with encryption support, if it's not completely objected 😄

kerem commented

2026-03-13 11:54:57 +03:00

Author

Owner

@VShawn commented on GitHub (Nov 7, 2024):

database with encryption support is not a importance point. Developing UI interactions is the part that takes up the majority of the workload. encryption part is very simple—just encrypt the string before writing it to the database, and it's done.

as the code shown below, all we need to do is encryption the Json property if we choose the json-ecnryption solution.

https://github.com/1Remote/1Remote/blob/main/Ui/Service/DataSource/DAO/Dapper/Server.cs#L49-L60

In fact, the predecessor of 1Remote, PRemoteM, did have a database information encryption feature based on RSA. However, during the refactoring, the encryption module was discarded due to the large workload.

And in PRemoteM there was only one database, the problem is not that complex. However, now users may have multiple databases, each database may has a different key, the required UI and validation control logic become more complicated.

@VShawn commented on GitHub (Nov 7, 2024): database with encryption support is not a importance point. Developing UI interactions is the part that takes up the majority of the workload. encryption part is very simple—just encrypt the string before writing it to the database, and it's done. as the code shown below, all we need to do is encryption the `Json` property if we choose the json-ecnryption solution. https://github.com/1Remote/1Remote/blob/main/Ui/Service/DataSource/DAO/Dapper/Server.cs#L49-L60 In fact, the predecessor of 1Remote, PRemoteM, did have a database information encryption feature based on RSA. However, during the refactoring, the encryption module was discarded due to the large workload. And in PRemoteM there was only one database, the problem is not that complex. However, now users may have multiple databases, each database may has a different key, the required UI and validation control logic become more complicated.

Rows
Columns

[GH-ISSUE #755] use a password to protect the sqlite database. #3538