Allow changing the archive passphrase?


The tricky part about doing it for non-advanced users is Duplicati has to carefully convert all the data in-place - without somehow ending up in a broken state.

Duplicati doesn’t currently support restoring from or backing up to a mixed encryption backend, which means it wouldn’t be possible to use the backup until the conversion is complete. And then there’s the whole aspect of dealing with resuming the encryption, which also has to be carefully implemented.

A workaround for that would be to have the user specify a new directory to put all the converted data, but not everyone has capacity to double their backup size for a week (or four) while it’s being converted.

The script is simple from a programming perspective because it can ignore all these things, but it’s not user friendly.

I definitely agree that it’s a necessary feature to have both for enterprise and for regular people. I’m just not a fan of the “re-encrypting all the data” approach, as I argued in [feature request] Changing volume encryption password · Issue #2991 · duplicati/duplicati · GitHub

I think my thoughts on this back when I opened #2991 was to insert the key into each dlist file and then having those be password protected so you minimize the amount of re-encryption work.


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.

Yes, but is it “enough” to simply change the keyfile passphrase? I think it can give a false sense of security if your real key is compromised and you simply change the passphrase on the keyfile, because the attacker might have the contents of the keyfile when you discover that the passphrase is compromised.

In this scheme, the dlist files would be encrypted with the user supplied passphrase, and all others with a session key? This makes it easy to determine what key to apply (just look at the file extension). If we do not store the encryption key locally (should we?) then we need to fetch a single dlist file before being able to start a backup.

This would cover (1) and make it a bit more robust against (3). And I think this can be implemented without many issues, except for supporting existing backups where the user supplied passphrase is used to encrypt everything.

I guess we could make the simple approach where we support a list of potential passphrases (should be a short one, less than 5 items) and then just try with each one until we succeed. Then we grab the passphrase from a dlist file (if it has one) and adds the user supplied passphrase to the list and then just attempt to decrypt.

When changing the passphrase we would need to re-encrypt all dlist files. The problem here is that we can be interrupted and end up with some files using one passphrase and others using the new passphrase. It is a bit messy, but we could mark the database as being in “re-encrypt mode” to avoid other things happening. Then we can continue with the user supplying both the old and the new passphrase, and use the same approach with a list to detect if the dlist is already re-encrypted or not.

It still does not solve (2), which I think can only be solved with a re-encryption of all files. We could add new encryption keys to the dlist file, such that it knows how to decrypt old files, but uses a different passphrase for encrypting new volumes. It is a bit dangerous, as we need to ensure that we only remove old keys when there are no old volumes depending on it.


Good point. I think it’s a great start if we can make the described process robust to the point where it can function in a partial state with multiple keys. That way we can comfortably offer at least some protection.

Then I’d suggest a next step where we offer to re-encrypt all the data in an amortized fashion. So we re-encrypting X volumes each backup, with an option to force re-encrypting everything in one go.
Even if the “all in one go” approach is interrupted it will then just continue over the next backups to finish the re-encryption process.

I think we should. It’s not much more secure to have it only on remote since the DB contains the info to download and decrypt the remote data anyway. The security implications are not any worse than the current (which won’t be resolved until we get OS password managers involved)