Hi. So what would be a save way to move the token files (2 one drive acounts for me) without recreating the storages? I’m running the Web version on a QNAP system.
Would this work:
Thanks
The web GUI stores the path of the token file, not the content of the token file. So if you want to switch to a different token, you just need to overwrite the existing token file with the new token.
What if you want to keep the same token, but move it to a new location? I just saved it to my Downloads folder, which I clear out periodically, but I found out the hard way that the file is needed for more than just the initial setup.
Now that I know, I’ll just not delete that one file, but it’d be much more convenient if it was moved to a more permanent location, like .duplicacy-web.
It might even be a nice future enhancement to move it there automatically during the storage setup.
Nice future enhancement would be to not save path to the token in the first place and instead treat its contents as a password and save them in the keychain (or configuration file, or environment variable).
For now the easiest would be:
Thanks, that did the trick.
And that’s a good point about protecting the path but not the contents of the token file.
If there was malware designed to find these one-token.json files, would it be able to modify the OneDrive account (ie delete the backups before encrypting the local filesystems, making restoring from backup impossible)?
Or is there some additional information needed to use these token files, which only Duplicacy would have (and is protecting)?
Yes; the token file provides access to the account with the requested credentials, which, until this is addressed means your entire cloud account. Granted, most cloud providers (I know for a fact about Google, but likely OneDrive has support for that too) provide a way to roll back your entire account for up to 30 days back so ransomware attack is not a concern; However information disclosure is.
Ideally the token content must be safeguarded better than the password (password alone is not enough to access your account since most likely you have some sort of MFA enabled; token file bypasses that; it’s effectively “application password” with a complication of renewing tokens for OAUTh that are served by a small script running at duplicacy.com but that is not important) and therefore the best place to keep it is in the keychain. If that is not available — in the users home folder with permissions set accordingly — e.g. see how .ssh manages that — in the default configuration if permissions are too relaxed ssh will even refuse to connect, because it would not be able to guarantee that access is authorized not by an impersonator.
For all intents and purposes no. Anyone who has the token can access files freely just like duplicacy would. After all, duplicacy is just a code that can authenticate with the service using nothing but the token file. You can write your own code they will do equivalent of rm -rf * and depending on what other permissions does the account have maybe clear the trash too. Or better yet — download everything first. Instantly. To another cloud. Or share to another account on the same cloud.
Personally the way I handle this (outside of long and convoluted albeit full proof process with service accounts described here Duplicacy backup to Google Drive with Service Account | Trinkets, Odds, and Ends) is by using a separate Google account for duplicacy to issue credentials from and sharing the folder from my main account with that account.
This does not require acrobatics linked to above, only uses published GUI services, and yet ensures that even if credentials are leaked only duplicacy backup store will be visible to the attacker which is harmless: it already has access to my data on my machine since it possesses the credentials to the cloud so no additional data disclosure risk; and if they nuke my duplicacy backup — google will restore it by reverting entire account.
Yes, I do realize that you use SkyDrive but I’m not familiar with what features they provide; I am however familiar with Google’s offering in that realm and hope there should be some overlap in functionality. Else — move to Google.
I really liked that idea, but it might not be supported on OneDrive.
@gchen This is the error I see when trying to add a new storage that points to a shared OneDrive folder:
Failed to check the storage at one://Duplicacy-Ree: Failed to load the OneDrive storage at one://Duplicacy-Ree: 400 Cannot perform operation within a mounted folder.
This is while it says Checking the storage at one://Duplicacy-Ree
The process I followed was:
Do you know if this scenario has been tested and is expected to work?
I wonder if “mounted folder” refers to the fact that I used “Add to my OneDrive”, and that has a reduced feature set? Without that step Duplicacy did not list the shared folder when I used the browse button though, so maybe Duplicacy needs to be updated to support shared folders directly?