duplicati stores the encryption password for user convenience. Hence there is no need to provide it when backing up, restoring or when running a command line via the GUI.
Is there a way to suppress this (at least for restore and running a command line from the GUI) so that the user has to know the encryption password to proceed?
Thanks!
I don’t believe so (though @kenkendk or maybe @Pectojin might be able to confirm).
In what sort of scenario are you picturing this sort of feature being used?
For restoring you could delete the configuration and restore directly from the files.
Using commandline from the web interface won’t work, but you should be able to run the commandline directly without any DB.
I guess I had been thinking that requiring the encryption password for restore or running a GUI command line would provide protection in case someone cloned my duplicati configuration (root access or even using the default Linux universal read permission).
On further consideration, this won’t really help. If they are able to directly retrieve my encryption password from Duplicati-server.sqlite, they can use it either in the GUI or in the command line.
The only solution would be to not store the encryption password at all, which would make automatic backups impossible.
So short of changing duplicati so in only accepts encryption passwords in the GUI and command line, but stores the actual encryption key (assuming the function is one-way) in Duplicati-server.sqlite, my idea won’t work. If such a change is made, then it would be worth reopening this topic.
Thanks!
The idea is that you always want your backups to run, with a minimum of maintenance and intervention. Having to type the passphrase before each backup defeats that idea, which is why it is not possible to not store it.
If you have some method for securely storing the password, you can use the option --run-script-before to retrieve it and set it.
My plan is to add keychain integration, such that the OS is responsible for storing the password. This gives the highest possible security; if the OS cannot guard it, neither can an application running on the OS.
I know that some people have set up asymmetric encryption with GPG, such that only the encryption key is on the client, and you need a private key to restore it.