Introduce a mechanism where passwords (and possibly other sensitive details) are kept separately from the configuration file

[joeyates]

Currently, when using a configuration file, passwords must be included as clear text.

While passwords are the most sensitive information in the configuration file, a user may wish to protect other data, e.g. email addresses or servers.

Let's explore the various options for doing this. The discussion was prompted by PR #248, which proposes a solution where an --env parameter instructs imap-backup to insert environment variables into the configuration in place of strings like $PASSWORD.

Motivation

Issue #167, indicates that it is useful to be able to make a backup of the configuration file, but doing so, with passwords in the file, is problematic.

Existing solution: single

There is already a mechanism for avoiding putting passwords in a config file, which is the imap-backup single command.

With this command, there are 3 ways of passing the password: --password, --password-environment-variable and --password-file.

The first can be used with an environment variable containing the password, e.g.:

$ imap-backup single backup --email [email protected] --password $PASSWORD --server imap.example.com

The second indicates the name the environment variable to use, e.g.:

$ imap-backup single backup --email [email protected] --password-environment-variable MY_IMAP_PASSWORD --server imap.example.com

The third indicates a file containing the password, e.g.:

$ imap-backup single backup --email [email protected] --password-file ~/imap-password --server imap.example.com

(See the output of imap-backup help single backup for all the available options for imap-backup single)

Of course, this approach only works when a single account is backed up at a time.

Possible approach: ERB Templating

A similar problem was resolved in Ruby on Rails. Rails allows the use of Ruby's native ERB templating to avoid putting passwords in config/database.yml.

Example of Rails' config/database.yml:

production:
  url: <%= ENV['DATABASE_URL'] %>

By default, Rails runs the file through ERB, so substitutions happen without further user intervention.

The advantage of adopting the same approach in imap-backup is that ERB is tried and tested, and is part of the standard library. It doesn't add dependencies and can be relied on to handle edge cases in substitution that an ad-hoc solution might not cater for.

Possible approach: Config File Encryption

One example of config file encryption is for Microsoft's ASP.net.

Encryption introduces complexity, and may just defer the problem, as the encryption system itself would have to be configured.

Users of imap-backup can already use encryption, without it being part of the software; one can use GPG, or any other system, to encrypt end decrypt the configuration file.

Obviously, the decrypted configuration file would need to be saved to disk, but it doesn't seem that this fact would make it any less secure than any other mechanism discussed here.

If this solution is workable for a large number of users, maybe it is sufficient to suggest this as a "recipe".

Possible approach: Do-it-yourself Templating

It is already possible to use a template file and inject environment variables without modifying imap-backup.

For example, with this content in config.json.erb:

{
  "version": "2.2",
  "accounts": [
    {
      "username": "<%= ENV['EMAIL1'] %>",
      "password": "<%= ENV['PASSWORD1'] %>",
      "status": "active",
      "folders": [],
      "server": "imap.gmail.com"
    },
    {
      "username": "<%= ENV['EMAIL2'] %>",
      "password": "<%= ENV['PASSWORD2'] %>",
      "status": "active",
      "folders": [],
      "server": "imap.foo.com"
    }
  ],
  "download_strategy": "delay_metadata"
}

The configuration file can be produced as follows:

[email protected] PASSWORD1=mysecret [email protected] PASSWORD2=letmein erb < config.json.erb > config.json

Discussion

Please propose your input/opinions/alternatives on this subject!

[l-monnier]

Thank you for the great description. It's not my place to comment – I will leave this to others – but I just want to point out that, despite of the name of the feature, my main motivation with PR #248 was to get a password prompt, so the password is not written on disk (having the possibility to use environment variables was somehow a side effect of the chosen implementation).

That being said, of course it might be considered as a completely different feature than the one of this current discussion. Also, this can be implemented with a bash script, without modifying image-backup (I initially did it for my own use).

[joeyates]

Version 16.3.0 adds the option of passing an ERB template instead of a straight JSON file.