Sensitive information storing

Developer
1

Hello everyone,
I am using duplicati a while now and have read a lot about the techniques used for storing sensitive information.
Correct me if I am wrong or something is outdated (I have seen many old posts)…

  1. Backup passphrases(also remote host info) are stored at the Duplicati-server.sqlite as plain text( I am using windows and couldn’t see the info of the db as I get the error message ‘this is not a database’).
  2. In windows this Duplicati-server.sqlite is being encrypted-Not that good for a hacker though- but no to other OSes.
    I have been experimenting with the backend lately and got the idea to add some code (duplicati\Duplicati\Server\Database\Connection.cs) to encrypt the data before storing them to the db and decrypt them everytime I retrieve them in LoadChildren() (duplicati\Duplicati\Server\Database\Backup.cs). Just so that they are not stored as plain text in the db.
    Would that work? If no, why?

Also, does the local database of each backup has any sensitive data?

I am a newbie in coding and security concepts in general so any help would be much appreciated.

2

The security of Duplicati-server.sqlite database encryption on Windows is mostly theater. The password is known to anyone who can read Duplicati code. Anyway, if someone has access to your computer they can easily get the password from the binary, even if you change it by recompiling Duplicati. If someone wants to access your Duplicati crypted data, they will be able to read Duplicati binary.

Your secret password should be stored somewhere else your backups would need you to be present at all times to enter it. The ‘where’ is the difficult part.

all the secrets to access the remote data in the cloud are in the master database, not in the backup databases.

That’s why you should probably not bother coding your own secure solution… I can recommend reading first the writings of Bruce Schneier.

1 Like
3

Thanks for the answer and the suggestions!

I am talking about the backup passphrase not the password of the Duplicati app. Unless that is what you are talking about too:/

I understand that and I dont want to cover this possibility as there is not much I can do in a way that the functionality of automatic backup wont change.
I am just concerned if someone has access at the filesystem of my computer and look the database. I dont want the passphrase of my backups to be visible. The encrypting/decrypting of the passphrase to be handled by my added code (which obviously someone can decompile the code and see-I am not concerned about it).

I will check them out, thanks!

4

I’m talking about the password of the Duplicati-server.sqlite encryption. Obviously the password that you set when creating an encrypted backup is NOT in the Duplicati code :slight_smile:

You can read Server\Program.cs around line 550, it is all explained there.

1 Like
5

Oh yes sorry I got a little confused :sweat_smile:

Thanks for the guidance!

6

It’s quite a complicated scenario with various reasons for protecting various things in various ways. Attackers try to locate weak spots, and defenders try to balance defenses against things users like.

hints at one fundamental difficulty. How does any code know access is legitimate and not pretense?
Some people have used encrypted filesystems. That’s good for data at rest (stolen laptop), but less effective after initial unlock. You probably already read about attacks and defenses, but I’ll continue.

If you worry about ransomware hurting your files and deleting your backups, that’s one problem type. Attempting to make your destination immutable is a defense. Another is guarding access credentials.

If you worry about snoops, any malware already on your system has direct access to original source, however guarding encryption passphrase will slow attacker if they access destination files somehow.

Beyond that, it’s adding layers of defense in multiple areas, attempting to make an attacker work hard. High value targets should worry more, as they may get live attackers – more capable than automation which sometimes aims more for a broad attack. A personalized human attack aimed at you is tough…

If you want your data to survive despite a completely compromised system, offline backups could help until physical disaster occurs, in which case online was more likely to be done. Keep multiple backups, however that increases chances of data survival but also increases chances of data exposure. Sigh…

Adequate risk mitigation sometimes requires thinking about which risks deserve the strongest defense.

I hope I’ve explored how “work” is a rather complicated concept, but you can protect at various levels.

The current database scrambling plan will have to change, as it’s been removed from newer DB libs…
An option being discussed which would help Linux users is selective encryption as you are proposing.

There are databases available that encrypt better than RC4, but then what of default DB passphrase? Leaving gaps in the defenses is a problem, but I don’t think anybody’s going to solve everything today.

1 Like
7

Just wanted to add to this issue that there is now a PR for a structured way to store credentials in “safe” storage (at least safer than having passwords in plain).

Once this PR is merged, you can use the OS keychain to store secrets, or any of the external providers.