Why isn't Duplicacy asking for encrypted storage password upon restore operation?

[JBow87]

Hello friends! New user here and I love how straightforward and effective this software is so far; backups are working fine and the size savings as well as the raw speed of chunk backups are a huge bonus.

However as it says in the title, I’m a bit puzzled as to why I am able to perform file restorations without ever being queried to input the password for a storage-encrypted repository (B2); I’m using the WebUI version and have my master pass set but not saved in any keyfiles so I’m assuming it only exists server side (which is how I want it)

However if anyone should heaven forbid gain access to my master PW, I still don’t want them to be able to manifest any of my data without entering the ‘storage password’ that I set up for my first B2 repo – and yet this is exactly how it functions now, I am never queried for that PW for performing restores.

Is this by design, and if so why? Is this key being stored and called somewhere in my local Duplicacy preferences? If so can I delete this entry somehow to force restores to prompt for the storage password?

Again glad to be here with you all after discovering this powerful tool, and looking forward to any info or suggestions you can give me.

Thanks!

[gchen]

The storage password to protect your B2 storage is stored in the configuration file ~/.duplicacy-web/duplicacy.json, but in an encrypted form. That is, you’ll need the master password to unlock your B2 storage password.

After you start the web GUI and enter the master password, all storage credentials are decrypted and remain in the memory. Therefore you can perform a restore operation without the need to enter the b2 storage password again.

[JBow87]

@gchen

After you start the web GUI and enter the master password, all storage credentials are decrypted and remain in the memory. Therefore you can perform a restore operation without the need to enter the b2 storage password again.

Ok this is sort of how I assumed it might be working, and I do get the logic for causing those credentials to persist as valid authentication during an ongoing session…

However, and as I’m sure you’re fully aware, the drawback is that Duplicacy ‘sessions’ are essentially left on 24/7 in order to facilitate scheduled tasks just like any other backup software solution. This presents a very obvious open attack vector if the machine is locally/physically vulnerable, e.g. with roommates, fellow students, malicious co-workers, etc.

Given this concern, is there any way I can achieve being prompted for my storage pw every time I perform a restore operation? Some CLI command, preferences change, or actions/details modifier in the WebUI?

The alternative would be to make the entire system completely locked down while idle/log off every time I go out and leave the machine, but I don’t want to go that route with my present situation (have to share the machine sometimes) and would rather do it at the application level.

@gchen

The storage password to protect your B2 storage is stored in the configuration file ~/.duplicacy-web/duplicacy.json, but in an encrypted form. That is, you’ll need the master password to unlock your B2 storage password.

Ok so, this raises another question for me (sorry if this has been documented before):
Does this mean that if someone simply sabotages the ~/.duplicacy-web/duplicacy.json file in some manner that I would lose the ability to perform backups and restores despite possessing all relevant passwords, or is there server-side storage going on to safeguard these credentials from being edited, destroyed or stolen locally? i.e., should I be backing this file up?

Thanks for your time and help!

[sevimo]

@JBow87

This presents a very obvious open attack vector if the machine is locally/physically vulnerable, e.g. with roommates, fellow students, malicious co-workers, etc.

Not to get sidetracked here, but if you assume that malicious agents have physical access to your box (unlocked even!), having unencrypted data in memory should probably not be on top of your concern list

[JBow87]

@sevimo

Not to get sidetracked here, but if you assume that malicious agents have physical access to your box (unlocked even!), having unencrypted data in memory should probably not be on top of your concern list

Hah yes, you’re not wrong!

To clarify though, these aren’t malicious actors per se; it’s just an open vector given my present circumstances.

The machine is not particularly vulnerable in the majority of use cases, and the small number of critical items that are at any given time on the machine are protected with basic authentication features. However, the machine is on 24/7, and it serves as a temporary repository for monolithic files I am offloading from local storage once I finish jobs for certain of my clients (media work). This makes it the perfect candidate for scheduled backups of said monoliths.

Thus it’s not that it’s something that’s likely to happen, just something that can potentially happen, because people are unpredictable, so I would like to be able to require basic password authentication before any restores can be performed on the machine (which is 100% reasonable)

[gchen]

@JBow87

Given this concern, is there any way I can achieve being prompted for my storage pw every time I perform a restore operation? Some CLI command, preferences change, or actions/details modifier in the WebUI?

This is exactly what RSA encryption · gilbertchen/duplicacy Wiki · GitHub is for. You’ll need the private key to run a restore operation.