First of all thank you for a great backup solution! Duplicati seems to tick everything I need except based on some reading in the forum, I gather that duplicate stores credentials in the clear.
Wanted to understand this a bit better. I suppose Duplicate handles 3 creds:
If I understand correctly, the service reffered to here is an online service? i.e., the refresh token and CID are stored encrypted in this serivce… not in the local computer where I am running duplicati? If so, does this mean, that if someone manages to get into my comp, despite
access to the duplicati db, the onedrive account creds are still safe and not compromised?
Does this apply to Google Drive as well?
Q3. Also, in the downloads I see two versions of duplicati: 2.0 which is in BETA, while 1.3.4 is not supported… Which is the stable supported version?
Any recommendations? This is for use in Ubunut 16.04 with Google Drive as backup.
This is stored better on Windows, where at least it uses an included version of System.Data.SQLite that allows the whole server database to be weakly encrypted using a fixed key (or your choice, if you prefer).
--server-encryption-key
This option sets the encryption key used to scramble the local settings database. This option can also be set with the environment variable DUPLICATI_DB_KEY. Use the option --unencrypted-database to disable the database scrambling.
Systems that are not Windows typically do not ship a version of SQLite that supports the data scrambling.
Windows being very uniform allows Duplicati to provide one, however third-party tools to read it are scarce which is a good thing because it impedes snooping with DB browser, and basic scrambling and database usage impede generic automated password scanning. It’s not foolproof, as one can turn off the encryption.
Are in some cases protected by the DB scrambling for all providers, and for some providers OAuth usage adds an additional level of difficulty as the actual credentials are not saved at the local system as you saw.
Credentials typically have to be presented directly to the storage provider’s API, so at some point they are memory-resident and could be stolen by an advanced attacker. Duplicati needs to authenticate to provider.
They’re not directly compromised, as they’re not in the database. An advanced attacker would have to get them from memory, or try to steal them from the OAuth server (assuming they were able to steal AuthID).
Yes, and to anything else handled by the Duplicati OAuth Handler. You can see a list (and a UI) at that site.
Neither. 1.3.4 is a 2013 release that is not supported. There aren’t even enough volunteers to support 2.0 ideally, which is one reason it’s still Beta (and response times can be less than ideal to forum and Issues.
If 2.0 works well enough, use it. There can be bugs reported, but usage is at 3 million backups per month, meaning percentage of problems is pretty low (unless you’re unlucky). Multiple backups is safest anyway.
Depending on what level they get to, system might be completely compromised, complete with keyloggers plus custom malware inserted or replacing original software. Duplicati can’t solve deep OS-level attacking which might even be done at the system drive level (encrypting drive will help) by reading/changing its files.
Unless you’re a high-value target, one typically uses layered defenses and hopes the attackers don’t get in. Just be aware that once somebody or something gets access, a determined attacker may often get more. Automated tools are less sophisticated, but a live attacker in your systems is a very bad security situation.
Thanks to BOTH of you. @f1_11 for asking a question I didn’t realize I needed an answer to and especially to @ts678 for giving such a concise but thorough answer and not losing anyone in the process.
@ts678 Thank you very much. Mine is Linux system, so the windows encryption is not an option. Good to know that the case of OAuth provides better resistance to a compromise. I total understand the points on key-loggers, in memory data, etc… these are beyond the control of duplicati and I am ok with it. My main concern was that, Duplicati being popular and open source, could have attacks that directly target the DB. So with your explanation, looks like the password that is exposed is the Encryption password.
What would be nice until we get a keychain/OS based integration is for duplicati to have manual backup mode… In such a mode, the backup is triggered manually by the user, the creds can be obtained from him, stored in-mem, perform the backup, wipe-mem. Thus not storing the password in persistent storage, limiting to having it in the clear in memory (possibly un-swappable if the OS provides support) only for the duration of the backup (or as needed).
Obviously, this solution many not apply to the majority of your userbase where the need is to do automatic periodic backups… but if it is isn’t something too difficult to do, It will make duplicati a feasible solution for those walking away from it because of the password storage.
It could also be storage provider credentials for some username/password provider not using OAuth.
Generally any value that would be needed for CLI (see below) is saved/retrieved for you by the server.
This is almost what any CLI usage demands, except shell scrollback and other history might add risk.
Two other mechanisms that might be available to you to work with human or shell keyring access (if it exists) to attempt to more securely obtain and supply values are parameters-file and run-script-before
EDIT:
Another disadvantage of putting secret options directly on the command line is that ps might show them.
I’m pretty sure these other option-setting methods won’t have that problem, but they would require setup.
Duplicati CLI interactively asks for missing encryption passphrase, but I don’t think it can for storage info.
