How secure is duplicacy?


#1

Over on the dupliacti forum they are discussing how to duplicati’s security:

I’d like to point out one comment by the duplicati developer in particular:

After thinking about this for a while, I see that we need to consider the attacker scenario.

  1. User exposes password (like password re-use, etc)
  2. Machine/network is breached
  3. Destructive malware/ransomware

If we use the keyfile approach, as duplicacy, we can only really cover (1).

If the machine is breached, they can easily recover the real passphrase, and changing the keyfile passphrase is no going to prevent anything.
Malware/ransomware can effectively kill the keyfile and make backups useless.

What does this mean for duplicacy? How secure is it? Or rather: what are duplicacy’s current vulnerabilities?


#2

Well, my opinion, in a simplified form: Duplicacy has to ensure the security of the files stored in backup in the cloud / storage. The scenarios cited affect all my files, not just the Duplicacy keys, and are outside the scope of a backup tool.

If you have bad habits with passwords, there is nothing Duplicacy can do. Solution: use a password generator / manager.

Keep your most confidential files encrypted. I use Veracrypt and AxCrypt. There is also Cryptomator and others. I travel a lot to work with my notebook, it can be stolen, etc.

Remember the “2” in the backup rule 3-2-1: 3 copies, 2 different technologies, at least 1 off site. Previously, “2” meant 2 media (HDD and DVD, for example). Today I use cloud and NAS. And specifically the Duplicacy keys and some more sensitive files I use another “technology”: Rclone. Even in the Duplicati forum topic, a user suggests using GPG and backing up the keys.

Perhaps something can be added to Duplicacy in terms of security, such as two-factor authentication. I don’t know the difficulty of implementing this, whether it would be a change in just some module or all software would have to be rewritten.


#3

2fa sounds like an awful idea (implementation wise): gchen needs to have a server always available (that means your duplicacy needs internet access – some may not want that) where to vouch for your code. If that dies by any chance (or someone poisons dns or whatever else) – bye bye backups.

There’s also the problem if how to handle typing the 2fa code? i (you, we?) use shell scripts and task schedulers for running our backups. how do we automate those to use a 2fa program?


#4

I completely agree. I also think 2fa does not apply well to Duplicacy.


#5

Guys, what you’re saying is all very interesting, but so far you’re not really answering the question posed in the OP…


#6

Agree…:roll_eyes:

Defined by how safe / good is your encryption password.

A example: you have to take care of your keyring files (if you don’t use environment variables). No one can have access to them and you should back them up by methods other than Duplicacy itself


#7

I mentioned this before, but if the password is compromised, changing it might not make a difference (depending on how far an attacker has got access to snapshot and chunk files). I don’t think this is a problem with Duplicacy in itself or can be mitigated - choose a complex password from the outset and, aside from any coding vulnerabilities, it’s probably about as secure as it’s going to get? (This is of course assuming an attacker already has access to your local/ssh/cloud storage.)

Aren’t those partially encrypted by the OSs keyring / credential management? And do you really need to back them up? They should be recreated when you enter the master password…


#8

I’ll do some testing on a different machine …


#9

This is true, but in this case the attacker would already have the access to the original files, so I don’t see the point of protecting the backups.

As long as the config file is untouched (which is stored in the storage), you should be able to access the backups with the storage password.