Potential for sensitive data leakage in backed up config files

[tgibson11]

1. The private config file may include IB account number, email address and password, and potentially credentials for other services if the user has made their own integrations.

2. When a production backtest is run, all config data, including private config, is dumped to a backup of the config file. (I'm assuming this data is not also stored in the pickled state file, but I'm not sure if that is the case.) This is already not great, because you probably don't want multiple copies of the private config data floating around, but there is more...

3. The run_backups process will copy the saved config to some location of the user's choosing. If it is backed up to an external drive on your local network, then it's not too much worse than having those copies on your PC. However, I suspect many users will want to do this backup to a cloud service, where it will be vulnerable to data breaches or other forms of unauthorized access.

So...do others think this is a problem?

Ideas for mitigation:

• Add warnings to documentation and/or in the example private config file
• Exclude private config elements from the backup (easy to do, but would probably cause problems loading a saved backtest)
• Exclude certain config elements from backups (ideally via config)
• Encrypt/decrypt backups using a user-provided key

[js190]

For me it's not too much of a concern for me as am not using the cloud for storage of model files or private config.
It's also a useful feature to see the full config echoed out for debugging purposes.

[robcarver17]

We have to store the config as you need a config to create a system object; using an empty or invalid config would cause numerous problems. This also makes it possible to delete everything in the cache and rerun, recovering the results from scratch if required.

I'd prefer documentation rather than code, as the latter creates complexity. Of the options involving code, I'd prefer the encryption option as it will touch less code, but ideally this would be done with a core python library so there are no more dependencies, and default to no encryption.

[tgibson11]

Since there doesn't seem to be much concern about this, I think I'll just add some notes to the documentation.

[bug-or-feature]

So...do others think this is a problem?

Yes, I think it is a problem. But I'm paranoid, I would rather not have any sensitive credentials at all in plaintext anywhere. I like the idea of excluding certain config elements from backups, ie '*_password'.

But perhaps a better solution would be to allow a config overrides from environment variables? With env variables having the highest precedence. I figured I'd have to implement this anyway if I ever deployed my app to a hosting service

[robcarver17]

Reading this thread, it occurs to me another quesiton is whether config files should be pickled with the rest of the backtest, rather than being stored seperately. There would be complexities, if for example you wanted to pickle a backtest and then switch to a new config, but I don't think this is a very common use case.