duplicati is accessed via the browser on the PC, which is fine.
But when I want to export or import config files, the browser stores and reads the files locally
Having to transfer the config files to and from a local filesystem is a security risk (in my eyes).
->
I want to store the config files in places on the NAS the PC (Windows) does not know about.
->
It would be nice to have the choice to handle this via the folder/file selection like destination and source selection for backups.
->
Local computer does not “know” about this then.
(Everything is kept on the remote system)
In my opinion this is “needed” on platforms with remote access.
the browser connection is a minor issue I believe, but to be on the safe side, https would be fine.
(Just searched for “https”: No result)
My main concern is it, to keep the job files in a “safe” place and further to make things easier.
Now I have to work as follows:
export via browser to PC to “public” area on NAS -> on NAS move to safe place
move from safe place to public place on NAS -> import from there
Maybe I’m a little paranoid, but on the other hand, why not reducing risks as much as possible?
Thank-you for clarifying. Is there a reason you don’t feel the “Encrypt file” option of “Export backup configuration” is secure enough?
The issue I see with what you’re wanting is that if Duplicati running on your NAS had access to non-public (“safe”) storage, your would then be trusting Duplicati to keep that non-public content private.
That means if somebody could get to the Duplicati web interface, then they could dig through all the supposedly private storage the Duplicati also has access to.
That being said, I suppose it might be possible to add another Export / Import job location as something like “Config folder” such that it would be stored wherever the Duplicati-server.sqlite or config.json file is stored.
However, that might give some users a false sense of security as, for example, on Windows, that folder would be %LOCALAPPDATA%\Duplicati which is likely NOT a private location.
You could also simply export “As Command-line” then copy/paste the contents to a file directly saved into your private storage. Though I do understand this only handles one side of your situation.
I suppose the other side could be dealt with by providing an “Import from Command-line text” text-box on the “Add a new backup” page.
If I would get totally paranoid, I would have concerns about keyloggers logging my password
You are right, encrypt the job files should be sufficient.
Ok, now I have question:
Are the credentials and type of connection for the remote location stored encrypted?
→
I’m going to use duplicati on my computer too and I want to be sure, that Windows (trojan horse, virus, …) has almost no chance to get an access to the remote backup location. Therefor I’m going to use SFTP, because Windows does not “know” this protocol.
If people have access to the Duplicati-server.sqlite file then they have all your settings including your backup destination password in plain text. It’s essentially the same as having access to the config file just in a database.
Here’s the SFTP settings in the DB:
To secure this, Duplicati would have to require a password on login and then decrypt those variables in memory. But right now it’s game over if they have your DB and decide to look in it.
I think it would be cool to offer full at rest encryption of the database assuming it didn’t tank the performance. But just encrypting sensitive fields might be enough.
That would be fine already, because, if “somebody” is already on the frontend, it does not matter, if he finds the files directly or through the data base. The data base might be more interesting in forensic means.
Well it depends on what you’re worried about. If you back up very sensitive data then you might be similarly worried about the fact that the databases holds information about all the backed up files.
Also it should be mentioned that encrypting just a few fields might be much more trouble to implement because it’s then implemented in the data layer instead of the SQL connector. Implementations in the data layer potentially has tons of dependencies around the code that then have to be updated.
If it is easier to implement it database-wide - even better
But it is as @Pectojin said: sensitive data or not - if somebody sits in front of the desk he/she/it has most likely access to the data anyway. BUT i think of usernames/passwords for all kind of destinations and encryptions that are stored in the db as well. And those he/she/it would not see so easily otherwise…
I have not spend too much time implementing this feature, exactly because Duplicati should be able to run automatically, and locking down the database prevents this (the user needs to type the passphrase, otherwise the passphrase is already on the system and the whole thing has no security). The RC4 scrambling is weak encryption, and it uses a well-known default password, so it only adds protection against casual hdd string searches.
Since full-disk encryption (or at least home-dir encryption) is standard on most OS’s, I think this provides better protection against many “cold” attacks.
That said, I would like us to implement “keychain” storage of sensitive values, such that the OS can protect these with the user credentials:
