Clear text password stored in Duplicati-server.sqlite

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 :slight_smile: )

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.


That ideally should be done sooner rather than later.

Due to default Linux file permissions, this password - which is a user’s login password on the target system - is by default open to the world for snooping.

1 Like

Is this something that could be added as a GitHub issue with a bounty added or is it complicated enough that it needs to be handled “in house”?

For reference, the only open issues mentioning “keychain” at the moment seem to be related to the GUI password.

How does one go about posting an issue with a bounty?

I don’t see any problems with handling this with a PR. The issue discussing the keychain integration is this:

After you create or locate an issue on Github, you can go here and register a bounty:

Anyone can claim a bounty, simply send in a PR and once it is accepted, claim the prize on bountysource.

@kenkendk @JonMikelV

I commented on GitHub (Duplicati file permissions on Linux reveals sftp passwords to all · Issue #3278 · duplicati/duplicati · GitHub), but in case it’s not noticed:

Ideally this should be implemented on a universal keychain that is available for Linux (KDE and Gnome at a minimum), Mac and Windows.

If such doesn’t exist, how would you feel if (at least initially) use of a keychain was only implemented on Linux?

My thought was to use an OS-specific implementation. I don’t think it is possible to make a secure cross-os keychain, as it requires some kernel protection to get right.

We have OS-specific code for the snapshots and tray-icons already, so the keychain implementation would have multiple implementations to hook in to the keychain available on the system.

OK - I posted a $50 bounty to have all passwords on a KDE Linux system stored in a keyring (probably KDE Wallet, but not a requirement).

Hopefully someone will notice and give it a go.


Thanks for kicking that off!

I’ve updated the issue to include that it now has a bounty.

My comment (currently at the end) indicated that this was for moving all passwords to a keychain. Does the title need to be updated to indicate that too?


Since it’s @kenkendk’s issue I’ll let him decide how that should be (I don’t actually know much about the topic so wouldn’t want to “mis-speak” in the title). :slight_smile:

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.

When I browse this file with sqlite browser it asks me for a password. Is there a default password

Not on Linux. But I think I read - but I’m not sure - that there is a password on Windows.

Yes, the Windows (only) database is RC4 “encrypted” but I’m not sure what the password is.

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:

1 Like