The only solid assurance against trojans is a destination that no program on the computer can destroy permanently. Some destinations (e.g. Office 365) have versioning that could be useful to do a rollback.
The reason for this is that no matter how securely you store destination credentials, at some point they actually have to be used to access the destination, and therefore are available to sophisticated attacks.
Programs can be examined with debuggers at that point, and all of the decrypted secrets can be seen.
This is quite easy. Debuggers are used all the time during program development to look at variables…
DLL injection is a way to get programs to do what one wants, common enough for a Wikipedia article.
Possibly Duplicati’s use of .NET Framework or mono add a level of indirection (it’s not in native code).
Another way to get a program to do what you want is to just replace that program with a changed one.
Passwords can be intercepted through keystroke logging. There are a lot of ways to get credentials…
Once there is an attacker on your system, the system is taken, so I hope backup is safe from system.
Automated malware is probably less sophisticated, but as you note, malware technology is improving.
Obviously an offline backup is pretty safe, but an online backup that doesn’t allow deletes or overwrites almost works with Duplicati if one sets no-auto-compact to stop compact. You also keep all versions…
The end result is that unless there’s a maintenance window to allow cleanup, backup history builds up.
The more subtle issue is that uploads that fail are retried with a different name, and old one is deleted, therefore if a destination gets half a file (likely easy on files, harder on clouds), delete is a noisy failure.
There are several posts on the forum from people who are trying this. I’m not sure how well it’s going.
Similarly, cloud storage vendors seem to be increasing their support for limiting what can be changed.
This is an evolving area because, as you say, it’s a bit of a race between the attackers and defenders.
Some schemes that look good at first glance (e.g. no deletes) may have holes (e.g. allow overwrites).
There are other reasons. Duplicati has a command line version that may run from cron or a scheduler.
This needs to get credentials while running unattended, meaning it can’t ask the user for the password.
As for the GUI password, you’re most likely typing it over an unencrypted (non-HTTPS) connection, so there’s a network packet interception possible. One can set up server encryption, but most users don’t. There’s some difficulty because (unlike SSH), SSL/TLS requires one to arrange for a server certificate.
The list goes on and on. If there are security experts out there with more to offer, feel free to chime in…
For now, I’m still sticking with the idea that if the system gets taken over, a password is not assurance.
It is, though, a step in the right direction if one forces an attacker to hack running programs (which can happen – you seem to follow security, so you can look at some of the exploits that have been around).
Protecting data-at-rest (e.g. the database) has some value. As mentioned, Windows DB is scrambled which actually is encryption (not high quality though), with a fixed key that you can override if you want.
Clear text password stored in Duplicati-server.sqlite shows how to do this, and the future plan from the primary developer who unfortunately seems to be extremely busy – as are all of the too-few volunteers.
Linux is messy, as mentioned in linked posts. One never knows what one will find on some Linux distro. Having Duplicati supply database code of its choice on all the non-Windows systems seems infeasible.
There are lots of things high on the priority list, including reliability. Duplicati is still considered Beta level. Progress depends on volunteers, and there are very very few. You can even see this in the forum posts.
Forum is not an issue tracker. That’s in GitHub issues, and one good one where you can comment is at:
Fix not revealing stored passwords from the UI [$100] #2024 where last input was in 2019, and there’s a post that one person is using a VeraCrypt volume solution (which perhaps asks for a password at boot).
I’m not sure how well that protects the data in all ways, but it should help protect if computer gets stolen.
If you want manual changes, the home page of the manual says how. An issue might also be accepted, however how to phrase it is a question because, as I said, a password is not assurance against attacks.