While browsing Duplicati-server.sqlite, I noticed that in the Option table there is a passphrase row with a clear text password.
I was lazy setting up my test environment for duplicati, so I used the same password for logging in to duplicati, for backup encryption and for sftp login. (A horrible way to do things - don’t do this at home )
As a result, I don’t know which password I’m seeing in clear text. Anyone care to enlighten me?
You see the sftp login password. Duplicati needs to know the real password (to authenticate with the server) so we cannot store a hashed version. The login password is hashed and salted, thus not stored in clear (we only need to verify it on login).
We have discussed various encryption tricks, but it really boils down to having the decryption key present on the same system as the encrypted data, which adds very little actual security.
My plan is to integrate with the OS keychain, and let that guard the passphrases.
In the mean time, wouldn’t at least doing fake encryption (i.e. duplicati-internal obfuscation) on the password be a better short-term solution than storing it in plaintext? This would at least guard it from accidental discovery etc, and would require specific and targeted knowledge to take advantage of.
True. The RC4 scrambling feature is only available in the Windows version.
Yes, the default password is Duplicati_Key_42:
Yes, that was the idea with the RC4 encryption. It is not strong, and has a known password, but at least you cannot do string scanning on the harddisk to find the contents.
I am not aware of any plug-n-play solutions for Linux, so we would need to identify all the ways and places a password can be stored, and then handle each field with manual obfuscation/de-obfuscation.
Since the same work is required for the keychain integration, I think it would make sense to have a “fallback keychain”, that is an internal Duplicati keychain with a known password (similar to how the RC4 stuff works on Windows). We can implement this first, and then it should be easier to “plug-in” the real keychain implementations later.
So far this is the only drawback to Duplicati I’ve seen. To be fair I don’t know how other backup solutions deal with password storage. My workaround is to use the portable installation mode which moves the AppData folder inside the main program folder, then move that to a VeraCrypt volume. I use Smart Retention, a 3hr setting and an autorun.inf to run Duplicati when the volume opens. It should start missed backups as soon as it starts. Here’s a post with some links at SE: https://softwarerecs.stackexchange.com/a/55070/30586