Allow changing the archive passphrase?

Arh… I was referring to the “local database” for each backup, which does not store the passphrase.

The Duplicati-server.sqlite database with all backup configurations does hold a copy of the key, and this is what is used for the export command.

1 Like

The difference is that in the current setup, the passphrase is the only required piece of information. If we have some kind of deferred setup (passphrase unlocks the real key) then we add a extra item. This extra item would not be stored in the password manager, but needs to be handled somewhere else.

Not sure how to do it exactly. It cannot be inside any of the existing archives (need to decrypt to get the key to decrypt), and it cannot be appended to the files because then we loose compatibility with other tools (zip and AESCrypt).

This leaves the option of having a duplicati-keyfile.aes as an extra file. Every backup/restore would need to start by reading this file and decrypting it. Changing the passphrase would require reading this file, re-encrypting it and uploading it again (overwrite).

It is not a huge change, but I dislike that it is possible to remove all access to the backup simply by corrupting/destroying this single file.

1 Like

What’s the difference between removing all access by corrupting/destroying the keyfile (and all copies of it) and removing all access by forgetting/destroying the passphrase (and all copies of it)?

The passphrase is created by the user (hence the user has it), and is not stored on the remote destination.

The keyfile would be generated, and not immediately obvious to the user that they need to make a copy of it.

The keyfile would also be stored on the remote destination, making it easy for an attacker (or a broken disk).

It’s been a long time since I last created a password. All (except one) of my passwords are random strings created by a password manager. Most of them I have never even seen. The encrypted file containing them is stored both locally and in the cloud.

That’s why I’m suggesting to make it a (non-default) option. Whoever goes down that avenue will know what they’re doing. As long as it’s not visible in the GUI, that will be the case anyway.

Let’s say an attacker gets their hand on the keyfile. How does that make it easier for him/her to get access to my data (compared to the current situation)? The missing piece in both cases is the password, isn’t it?

To drive that particular comparison even further, let’s look at a situation where the attacker has the password (but not the keyfile). In the current situation that means your data is gone as soon as attacker gets access to the archive and there is absolutely nothing you can do about it (your only escape route is to better hide the archive or delete it).

In the keyfile scenario, you have two advantages: 1. the password alone is not enough, the attacker also needs to find your keyfile. And 2. you can simply change the password (i.e. create a new keyfile) and destroy all copies of the previous one.

This latter bit is the only tricky part I can see in this particular comparison: it’s tricky because the user has to understand that even when the archive password has been changed, the old password will still work in combination with the old keyfile. So that could lead to a wrong sense of security. But I’d still say that, overall, the keyfile scenario is much safer in situation where the attacker has the password and just as safe in situations where the attacker has the keyfile.

But again, I am not a crypto expert, so I stand to be corrected.

Yes. I was thinking of ransomware here, that would destroy the key to render your backups useless.

Wouldn’t a forgotten passphrase be a problem in both implementations? :thinking:

Anyway, Kenneth does bring up an interesting point of data corruption. While the probability of losing the keyfile to data corruption on s3 or similar services may be astronomically low, for local backups it would be high enough to be a concern. Let’s not forget, many of these local backups are stored on consumer grade hard drives. Although there are ways to to avoid this, such as storing multiple redundant copies of the keyfile, we should certainly be mindful of this drawback.

I just saw that duplicacy is doing precisely what I’m proposing:

1 Like

Simpler solution that makes it obvious you need to backup up keys: allow asymmetric encryption with GPG, anyone who understands how to generate a key pair presumably can take care of them, too. (Then again stories about millions in lost crypto currencies because of missing keys make me doubt, even that)

I think there should be option to change passphrase easily with GUI. For example, passphrase could be compromised and in that case it needs to be changed.

There is a tool (RecoveryTool.exe?) that allows this which helps indicate this is an advanced feature.

I suspect it’s not included in the web GUI because of the side effects of doing such a thing - such as the bandwidth and other resources needed to download, re-encrypt, and re-upload your entire backup.

I understand and agree that it is an advanced feature. But this is also a security feature. A user, even not advanced can have circumstances when he needs to change a passphrase as fast as possible no matter how many resources it needs (bandwidth, processing time, etc.). Thus I think it will be nice to have this feature in GUI accessible with few clicks even to the non-advanced user. Also, I think there should be the warning that warns the user before he starts the process of changing the passphrase that this process needs many resources.

I completely agree with that - pretty much any step that might take a long time (cough - database recreate - cough) should have that warning included. :slight_smile:

I don’t know how difficult it would be to get the “passphrase change” code either into the standard Duplicati server codebase or at least callable from it - @kenkendk would likely know (and maybe @Pectojin).

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.

1 Like

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)

As I understand it encryption passphrase is used to encrypt back up data chunks / files/ blocks. I don’t know if that’s the right approach. IMHO better option would be to use pass phrase as a seed to generate a 128 char long string [which in turn to become the encryption key], now encrypt and save this string in a file like a key file as well as in duplicati’s Database. Prompt user to save this key file. This way you can allow user to change the pass phrase which will then trigger in memory key file decryption and re-encryption as well as updating encryption key saved in the data base. As an additional layer of security encrypt the database record with the passphrase and decrypt re-encrypt when passphrase is updated.

Essentially data encryption key never changes for a backup set but the encryption key’s encryption passphrase can be rotated.

If the idea of loosing the encryption key file sounds terrible why not save the key file in the db, on the local disk and with the backup set and prompt user to save it else where?

Welcome to the forum @RaptorG

Thanks for continuing this discussion. Unfortunately, many of the previous posters participate less now.

If you read through this (and also [feature request] Changing volume encryption password #2991), much discussion involves where to save the encrypted keyfile, however like so many other features, somebody interested in implementing it needs to volunteer. Thank you for your recent forum help. Do you code too?

As a small side note, Duplicati’s commandline tools don’t use the Duplicati-server.sqlite database, however there are other ways to achieve redundancy, Which to use might depend a bit on what’s simpler and covers all the needed cases, including all the command line tools, and also the Python restore script .

Hi, I work as a Primary & Object Storage Consultant for one of the Top 5 Data Storage vendors. I do code a little from time to time but mainly limited to automation scripts.

Thanks for the info. If you code in C#, JavaScript, or Python occasionally, that would be especially useful.
There should be plenty to do, if you wish to contribute a pull request someday. Even the ability to read the current code somewhat is very useful to trying to understand problems or propose good ideas to coders.

That’s kind of what I do, because my programming languages are almost none of what Duplicati is using.

Automation scripting might also play into some of the test suites, and there are others that could help a lot.
For large-data slowdown, large-data needs to be created, then Duplicati run to see how the SQL slows…
Robustness against network failures, reboots at sensitive times, etc. all seem like things on can automate.