CloudFusion icon indicating copy to clipboard operation
CloudFusion copied to clipboard

Support Dropbox access token authentication via environment variable (instead of username/password)

Open posita opened this issue 9 years ago • 2 comments

ff4d supports (requires, actually) authentication to Dropbox via access token. This is nice, because it doesn't require storing secrets and passwords in plaintext files. Consider something like:

% # Note no `[auth]` section
% cat ./config.ini
[store]
name = dropbox
cache = 60
metadata_cache = 120
type = chunk
cache_size = 5000
hard_cache_size_limit = 10000
% DROPBOX_ACCESS_TOKEN=... cloudfusion --config ./config.ini /Volumes/dropbox
...

This allows doing things like:

% # Encrypt access token
% openssl bf -in /dev/stdin -out access_token.enc
enter bf-cbc encryption password:
Verifying - enter bf-cbc encryption password:
[PASTE OR TYPE ACCESS TOKEN]
^D
% # Decrypt access token on a per-use basis
% DROPBOX_ACCESS_TOKEN=$( openssl bf -d -in access_token.enc ) cloudfusion --config ./config.ini /Volumes/dropbox
enter bf-cbc decryption password:
...

That way, not even the access token is stored in plaintext on disk. Because it's an environment variable, it won't show up in ps or top. Because it's not directly part of the command line, it won't be stored in shell command histories.

posita avatar Oct 10 '15 23:10 posita

I did not develop CloudFusion with a hostile runtime environment in mind. So I strongly advise against using CloudFusion if you are concerned about such an attack. That being said, it is generally a good thing to be cautious. If you don't want to store your credentials as plain text, you can start cloudfusion without the --config parameter, and generate a complete config file with your password in memory before copying it to mountpoint/config/config. Also, you can pass a configuration file without username and password, and manually edit mountpoint/config/config to add your credentials.

joe42 avatar Oct 11 '15 11:10 joe42

With all due respect, hostile environment or not, it's still a good practice to use token authentication instead of directly storing the username and password. If you would consider adding it to the roadmap, that would be awesome.

Are there any technical limitations with respect to the design or architecture that might make it hard to implement?

amjd avatar May 09 '16 12:05 amjd