Use "passcommand"s instead of passphrases

[piegamesde]

• I have searched open and closed issues for duplicates.

---

Environment info

• Duplicati version: 2.0.3.11_canary_2018-09-05
• Operating system: Arch Linux
• Backend: SFTP

Description

Currently, we have a lot of problems with passwords stored in plain text:

• The general backup password
• Potential ssh login passwords

are both sensitive data and both are potentially stored unprotected in the configuration file. There are some things to avoid this issue:

• Use asymmetric encryption
• Login using ssh keyfiles from the system's keyring
• Request passwords using password manager

The last one is a nuisance: there are a ton of different password managers and it is impossible to cover them all. The backup tool borgbackup thus has had a genius idea: instead of storing the password, take in a command that will be executed to retrieve the password. This way, everyone can create commands and scripts to retrieve passwords from the most obscure password managers themselves. And since borg has a few already documented, Duplicati would get them basically for free.

[digulla]

Twist on the idea: Slightly change the --passphrase option to use a prefix. This is similar to what OpenSSL does.

Examples:

--passphrase=pass:this is the passphrase
--passphrase=env:variable_name
--passphrase=file:pathname
--passphrase=fd:number
--passphrase=stdin
--passphrase=cmd:/path/to/command

To ease the migration, print a warning if the passphrase doesn't start with a known prefix and use it as if there was "pass:" in front of it.

Bonus level 1: For the file: option, check that the file is only readable by the current user and print a warning (incl. instructions how to fix it).

On Linux, that would be chmod 0600 pathname. On Windows, a short explanation how to remove all permissions from a file. Mac: Probably like Linux?

Bonus level 2: Add a command to generate a passphrase file with the correct permissions.

Bonus level 3: The command should add a backup job to backup the passphrase file to an USB stick. Ask the user for a simple passphrase to encode this one because that passphrase will be used rarely and it might take years before the user needs it again - but when they do, all their data might be at stake. Alternatively, refuse to encrypt this backup and just make it clear that the user must keep the USB stick in a safe place. Safe means here: 1) where they will find it again, 2) where it won't be overwritten by accident, 3) where other people probably won't find it.

[sergethedev17]

This is a good idea but the proposed solution would be a breaking change. Everyone uses --passphrase without prefixes inside the value. We should avoid breaking everyone's backups.

First suggestion: add new --passphrase-dynamic, --passphrase2 or --passphrase-from parameter. The suggested names are lexically close to the --passphrase parameter and will appear close to it in documentation etc. The new parameter can be used for advanced configuration (simple use cases don't need not both to learn about it) and can implement prefix-handling, as proposed by the OP.

[piegamesde]

@sergethedev17 I think you misread things. I didn't propose what you describe, my proposal was to use a generic --passcommand option that covers a lot of the later mentioned use cases.

Regarding your proposal, instead of adding a whole new flags with weird names, what about simply adding a --passphrase-type flag. It specifies what action should be done to the --passphrase value, defaulting to plain passwords for backwards compatibility (and because it's sane).

[sergethedev17]

@piegamesde, I was concerned that @digulla 's examples (eg --passphrase=cmd:/path/to/command) would constitute a breaking change. Thanks for clarifying your OP. I understand now that your suggestion is to add a new --passphrase-type parameter that, when provided, would change how the --passphrase value is parsed. For example:

duplicati.exe --passphrase=DUPLICATI_PWD_ENVVAR --passphrase-type=env

This definitely resolves the breaking change concern. However, to me it still does not look right that we would be storing file paths and other references in the --passphrase parameter. This is mainly due to the ordinary meaning of the word passphrase.

How about two new parameters: --passcommand-type and --passcommand? For example:

duplicati.exe --passcommand-type=env --passcommand=DUPLICATI_PWD_ENVVAR

I am not very familiar with this repo/project. The repo maintainers are probably best placed to suggest which parameters should be added and how they should be named. @warwickmm , could you weigh in on this please?