Can the tokens and password be used to access encrypted files?

Help and Support
1

Assuming that the rclone.conf file isn't encrypted, can the tokens and passwords for the encrypted remotes be used to first access the remote and secondly decrypt the encrypted files?

I presume that the tokens can be (ab|mis)used to gain read and write access to the remote destination and if compromised have the option to be revoked from the cloud provider's web interface e.g. connected apps.

Are the passwords simply a one way hash to authenticate a password i.e. the hashes without the actual password are meaningless and useless as well as cannot be used to decrypt files?

2

if you rclone.conf is not encrypted, anyone could just use it to access to encrypted remote.
if they wanted the tokens, password and remote info they could do a rclone config dump and get this

"secret": {
    "directory_name_encryption": "true",
    "filename_encryption": "obfuscate",
    "password": "DRYIQjfkKkpwrCcH0ENfAkYcbhSIpwt7",
    "password2": "e1hvL9TBATXRbR0or6M25Xl7_92Ro9yd",
    "remote": "remote:bucket",
    "type": "crypt"

about the encryption used to encrypt rclone.conf, read the docs here
https://rclone.org/docs/#configuration-encryption

3

Assuming that the passwords are leaked and a downloaded copy of the file is made available, can the passwords be used to decrypt the file?

Equally, if only the remote's token is accessible, I assume it is sufficient to access the remote destination (without the password).

4

that is a good question and i do not,for sure, have the answer.

but i would say yes, that i could create a new encrypted remote and use the passwords.
perhaps @thestigma might know?

5

I was wondering if the passwords could be used to decrypt files without the need to create a new remote.

The use case is the the passwords are leaked and the encrypted files are made available. Can the passwords be used to decrypt the files?

6

Yes, that would be quite trivial. Obviously the perpetrator could just use rclone to decrypt - or if they were more technically inclined they could view the source to see how the encryption works and code the decryption it themselves. Making a new remote doesn't really factor into it. If you have the encrypted files + passwords you can decrypt locally without ever accessing a remote server.

If you lose your crypt keys then the encryption is no obstacle whatsoever to someone who has those keys. For this reason you should only use your crypt keys on systems you consider secure and private. Ideally one that you do not also use for risky software and downloads that might contain viruses or malware. Further obfuscating them is possible (ask asdffdsa as he has some of his own methods for this) but all that really does is make it less obvious where the password is stored, so while it would probably foil automated viruses gathering data it's unlikely to stop a competent targeted attack (which is realistically unlikely to happen.
This isn't really any different from any other storage though. The situation would be the same if it was local storage. If the perpetrator gained system access to get your passwords it's unlikely it would really matter where the actual files were stored. If you can reach them then anyone with the same info could (including local).

There is really no way of securing against a full system penetration when that system has access to the passwords though. Not unless you are willing to input them manually on each startup (+ encrypt your memory to protect from in-memory snooping). That is to cumbersome to be practical . Thankfully that is also unnecessary in the vast majority of cases.

As for the token leaking alone - they MAY potentially be used within a quite limited timeframe to access your files (they are periodically refreshed) but if the files are encrypted they would still be unusable, when the token expired it would make the information invalid or at least alert you to the issue. The token alone leaking would be pretty unlikely to be a big security problem in most cases. At least unless someone where specifically targeting you for some reason, which is extremely rare. It's something to avoid, but very unlikely to actually cause a problem.

7

How could a perpetrator introduce code that would decrypt the files without knowing the password?

Can you elaborate on "not using for risky software and downloads? My understanding is that if the rclone.config file is encrypted with a sufficiently complex and unique password, the ability to decipher any content is limited. Why would there be a need to obfuscate?

I am assuming you are referring to full disk encryption such as LUKS, BitLocker, Veracrypt. If yes, a password is required to decrypt the partitions. I wasn't aware that it was possible to encrypt memory.

As for the token leaking alone - they MAY potentially be used within a quite limited timeframe to access your files (they are periodically refreshed) but if the files are encrypted they would still be unusable, when the token expired it would make the information invalid or at least alert you to the issue. The token alone leaking would be pretty unlikely to be a big security problem in most cases. At least unless someone where specifically targeting you for some reason, which is extremely rare. It's something to avoid, but very unlikely to actually cause a problem.

To clarify, I am assuming the token stored in the rclone.config file is similar to a development token that has authorization attributes. Why would this change? If this token is leaked, I imagine that the application permission would have to be revoked.

8

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.