Clear text password stored in Duplicati-server.sqlite

[sylerner]

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?

Thanks!

[kenkendk]

@sylerner

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.

[sylerner]

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.

[JonMikelV]

@kenkendk

My plan is to integrate with the OS keychain, and let that guard the passphrases.

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.

[sylerner]

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

[kenkendk]

@JonMikelV

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”?

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

Fix not revealing stored passwords from the UI [$100]

@sylerner

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

After you create or locate an issue on Github, you can go here and register a bounty:
https://www.bountysource.com/teams/duplicati

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

[sylerner]

@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?

[kenkendk]

@sylerner

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.

[sylerner]

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!

[JonMikelV]

Thanks for kicking that off!

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

Issue: Fix not revealing stored passwords from the UI [$100]

[sylerner]

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?

Thanks.

[JonMikelV]

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).

[drakar2007]

@kenkendk

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.

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.

[saviodsouza]

@sylerner

While browsing Duplicati-server.sqlite

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

[sylerner]

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

[JonMikelV]

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

About Duplicati Security

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 …

[kenkendk]

@sylerner

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

True. The RC4 scrambling feature is only available in the Windows version.

@saviodsouza

Is there a default password

Yes, the default password is Duplicati_Key_42:

duplicati/duplicati/blob/master/Duplicati/Server/Program.cs#L517

@drakar2007

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.

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.

[John_Smith]

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