I’m new to Duplicati, and this forum, so pardon me if there’s a better way to post this, but…
I am evaluating Duplicati as my backup solution after losing CrashPlan, and I like the backup functionality, but I am looking to try to improve the reporting (email) capability, so I started experimenting with a post-run script, and in that script I dumped the contents of the DUPLICATI environment variables to a text file. I was shocked to find, not only the backup Passphrase in plain text, but also the password to my email account, via the send-mail-password variable! Worse, these settings are (momentarily) stored in a file, in plain text, in the temp folder. This seems to be a very significant security risk. If I were rogue, it seems that it would not take much to develop an app to monitor the temp folder and grab the contents of the file when it appears. Am I missing something here, or is this a legitimate concern?
[EDIT] - My apologies, the file in the temp folder does not contain the passwords - only the environment variables. Even so, a rogue process could do a memory dump and discover these plain text passwords!
It sounds like Duplicati isn’t doing proper sensitive data protection. Client passwords are a big one since Duplicati talks to many 3rd party services. Good memory storage practices for credential data:
At process start, code generates key for symmetric encryption
Wait till the last moment to read credential data from persistence storage. Encrypt sensitive credentials with process random symmetric encryption. The sensitive credentials could be in memory for a while if the task is a long running.
Decrypt symmetrically encrypted credential as privileged task is executed.
Securely delete unencrypted sensitive reference: Overwrite length of variable content with 0/NULL. Then unset. I know .Net has functions for this. I know keepass2 uses them.
Make sure process encryption key is securely removed at process exit.
Does it protect from everything, no. There is no way to completely solve this. Does this protect against casual memory snooping, yes.
All password should be stored as cryptographically secure seeded hashes. SHA2 class hashes
That is handled. All passwords that are stored/validated by the server are hashed and salted.
That is possible with SecureString. It is not currently used anywhere in Duplicati.
The setup you describe, increases resistance agains memory attacks, but adds no real protection as long as the stored credentials are not properly encrypted. If an attacker can simply read them from the database, there is no need for them to waste time on memory dump/snooping.
Until we implement proper credential storage with a protected key, guarding in-memory passwords is a low-priority task for me. So far the most promising solution seems to be using the OS KeyChain features, and then rely on the OS being able to guard that secret.
Once that is accomplished, we can rewrite all handling of passing credentials.
Isn’t the configuration database protected by the --server-encryption-key parameter ? I know right now that defaults to RC4 which has slew of issues. One being that RC4 is a broken cipher. The other is that the RC4 support is not really cross-platform friendly with SQLite. I would recommend we switch of to AES. AES is well trusted and and well supported. On top of that, most platforms have hardware acceleration for it so it usually well performing cipher if performance is a concern.