Could someone explain in some more detail what --allow-passphrase-change means?
The official help text says no more than this:
Use this option to allow the passphrase to change, note that this option is not permitted for a backup or repair operation
Both parts of that sentence are unclear to me:
Use this option to allow the passphrase to change
To allow the passphrase to be changed when? And by whom? Does this mean that if I set this option to false (which I believe is the default), I will never ever be able to change the passphrase for my backup archive??
note that this option is not permitted for a backup or repair operation
Uhm, isn’t that just about what duplicati does: backing up and restoring??
The files uploaded are encrypted with the passphrase you choose. Because of this, changing the passphrase will mean that:
you cannot read existing files
new files will be encrypted with a different passphrase
In other words, you would need two passphrases to restore the backup. For this reason Duplicati actively prevents you from changing the passphrase.
In some very special cases you may want to use another passphrase than what the database has recorded (the passphrase is not stored in the database, only a hashed value).
Okay, I understand. In that case I’d like to suggest a security feature (?) that allows changing the passphrase for the entire backup. I suppose that would mean that the password actually used to encrypt the files would have to be randomly generated by duplicati internally, and that password would then be encrypted with the user’s password so that when the user enters the password, duplicati can decrypt the encrypted password to access/encrypt the files. Basically like hardware based encryption of hard drives, except that it’s not hardware based.
The reason why I consider it a security feature is that it allows me to change the archive password once it has become known (for whatever reason). But I don’t know what the disadvantages of my proposal might be…
Yes, I understand why you would want it, but there are only two ways to do this:
download, re-encrypt, upload
store a key file with the real password
Option (1) is going to be super slow. You can use the Duplicati.CommandLine.RecoveryTool.exe to re-encrypt the files. The tool Duplicati.CommandLine.BackendTool.exe can upload/download for you.
Option (2) is mentioned in the link @mohak posted, and it has the disadvantage that you have a really important intermediate file, giving a single point of failure.
Single point of failure, yes, but is it a disadvantage? “Disadvantage” implies that it makes the situation worse than it is now and since the current situation can look differently, depending in what (type of user) you have in mind. So let’s take a more detailed look: what current situation are we comparing the keyfile scenario with?
Some propositions:
Long passphrases are used
Since the passphrase is long and cannot be changed, it has to be stored somewhere outside the users brain
The most popular storage place is probably a password manager.
If these are reasonable assumptions, what exactly is the difference to the keyfile scenario? It seems to me (but I’m by no means a cryptoexpert) that the password manager also constitues a single point of failure. The difference is then that the user knows about it and treats it with greatest care (e.g. backs it up) because it also holds lots of other passwords.
So, as has been pointed out in the google groups discussion, the challenge is to find a way to create that kind of awareness also with respect to the duplicati key file. Perhaps this could be achieved by letting the user choose between a single-auth and 2-auth backup, when creating a new backup job: A single authentication backup is what we have today. A double auth backup would be one with a keyfile, i.e. where the user knows that to access the archive, two things are needed: passphrase and keyfile.
If a rudimentary (i.e. command line) version of this can be implemented without too much effort, I would like to suggest that it should be moved up the priority list a bit, simply because making password change possible already now would safe so much hassle of downloading and reuploading huge archives in the furture.
Another thought: I would say that the possibility to easily change the password for the entire archive also has security benefits compared to the current situation where this is not the case. So perhaps the question is not so much about more or less security but what kind of security. I would guess, for example, that in the business context, it might be important to be able to change the password (e.g. when an employee leaves).
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.
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)?
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.
Wouldn’t a forgotten passphrase be a problem in both implementations?
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.
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.
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).
