I think there are a few issues mixed up in here.
There are different credentials:
- Remote store credentials
- Backup encryption phrase
- Database password
- Service password
- OS credentials
As Duplicati is supposed to run backups regularly without user intervention, it is difficult to balance the need for security with the need for simplicity.
For protecting the files on the remote store, the files are compressed and encrypted, cutting off attacks on the files.
Once an attacker has access to your system, it is generally “game over”. If your system is running, passwords are in memory somewhere and can be extracted. But there are ways to make this harder.
If Duplicati is not running, the attack vector would be to go after the database. In the current setup, the settings database contains the server url, the server credentials and the encryption passphrase. To mitigate this a little, the SQLite database is scrambled using the RC4 cipher with a default password (and on Windows only). The purpose of this is to make it harder to do string scans of the harddisk, but it is not supported on Linux and it does not add any real security.
Duplicati needs the information in the database to make backups. If the database (or just the sensitive fields) was really encrypted, the user would need to enter the password on startup, making automatic backups impossible.
The plan is to use the OS keychain facilities to store sensitive information, but no progress has been made on this.
For the OP the TrayIcon needs to know the password, otherwise it cannot connect to the server and display the current status. We also have plans to add a “read-only” mode, which would make this a little simpler. We are using this to create a valid session, and pass the session token to the browser if you open Duplicati from the TrayIcon. I can see why it is confusing, but I consider it safe, as anyone that has access to interact with your desktop can do many other nasty things already.
I will also state again, that the webserver running in Duplicati has not been security vetted and I strongly advise against exposing this to the internet (by default it accepts loopback connections only).
Yes, this is a real threat and very hard to fix. Duplicati needs to know the encryption phrase and the remote server login credentials to work.
You can mitigate it by using GPG encryption with public-key encryption, such that the private key is not present on the machine. But since the attacker already has access to all your files on the compromised machine, I am not sure it helps much.
You can also set up the remote destination to refuse delete and overwrite. Duplicati needs the advanced option --no-auto-compact --keep-versions=0 to disable any deletes (overwrites are never done).
This last option will keep you safe even if the machine is taken over by malware that explicitly seeks to destroy backups, at the expense of never releasing space (backups grow infinitely).