On password obfuscation

I understand the current way that rclone obfuscates your password is with reversible encryption as to prevent eyedropping (casual reading of the config file).

I was thinking if it would be advantageous to use a salt to encrypt the password and store the salt in a file on the remote end only. So when decrypting, rclone would download the salt and use it to decrypt the password.

However, I then realized that the client_secret and token are also stored in the config file (at least for Google Drive), so I suppose this method wouldn't really give you any real security as an attacker could just access your cloud service.

However, I don't really know much about these topics so I thought I would toss this idea out there.

This is kind of a chicken and the egg problem.
Your system needs to know certain info to use the cloud drive, so that info (or the means to get that info) needs to be stored locally somehow. There is really no way to both let the system have access (directly or indirectly) and also not store the secrets that risk being stolen if the system is compromised.

Unless of course you want to type in a password and effectively "store a key in your mind". Or on an USB, or piece or paper or whatever. rclone has a function that lets you do this. It can just be a hassle to deal with as you generally want stuff like this to run automatically and not require a bunch of passwords each time they start.

The options really are - either to store a critical piece of information (such as the key to decode the config) outside the system as I mentioned.
Or...
Use some scripting to obfuscate as much as possible - preferably in a non-standard way. Obfuscation can always be defeated, but it if it's not handled in a standard way it is usually enough to discourage it from being picked up. Very rarely are you as an individual personally targeted after all, and that just makes it not worth the effort to scour every byte of data for hidden secrets. Most intrusions rely on automation and a wide spread - so if it can't just pick up the obfuscated password easily in the standard place it's likely to safe you from disaster. @asdffdsa is kind of paranoid about this and uses some elaborate obfuscation on his setup. If this is the route you want to go - you might drop him a PM and ask him to share some techniques and script-bits.

Personally I think that so far rclone is not large-scale enough to really be a target yet. I have yet to hear about any malware that targets or is aware of rclone directly. I think the worst threat is probably just that something like randomware might affect mounted drives (like any other harddrives). This can be recovered via the trash-systems that most backends use though - or via rclone's --backup-dir and keeping this location outside what you mount.

This is kind of a chicken and the egg problem.
Your system needs to know certain info to use the cloud drive, so that info (or the means to get that info) needs to be stored locally somehow. There is really no way to both let the system have access (directly or indirectly) and also not store the secrets that risk being stolen if the system is compromised.

That's what I suspected. Thanks for the explanation!

I am working on a hobby project where I want to offer to store passwords in a config file. I think for my purposes it offers some benefit to use a salt to encrypt the passwords in the config file. This is because the data that is encrypted is a different file than the config file and the user might store it somewhere else. So I am planning to use salt from the data file to encrypt/decrypt the password stored in the config file. This way not only do I prevent "eyedropping" but also if an attacker only gets access to the config file he/she can't get the password without the data file (maybe a rare case but still some benefit unless I am misunderstanding something).

Yea, that would be a case of custom obfuscation as I mentioned.
While not a perfect solution - it is an extra layer of defense that will be a lot better than having it at all. Plaything that will take human intelligence to bypass is a significant hindrance to 99,9% of attacks.
The password can then be passed in via a variable for example. There are some threads on this that exist already.

1 Like