I recently just discovered that you can set an admin password on the UI. I had been against using the web UI entirely because I felt it was a bit of a security hole with the lack of password protection on it, but this changes things and I’m much more comfortable using it now. So I guess I’m kind of curious as to why there’s nothing encouraging the user to set that up on first use in the same way that the master password is setup. As a security best practice, it seems like a good idea to at least direct the user’s attention to it if nothing else.
I’m not the duplicacy developer, so below is just my personal opinion.
The fewer passwords and “security” is between the user and their data the better, especially with backup programs.
Duplicacy gui is listening on localhost. It’s already protected enough - to connect to it you have to be already on the local computer.
This is enough for vast majority of users, and they don’t need another set of passwords to manage.
I would go as far as removing the master password in favor of keeping the credentials in the keychain.
For rare scenarios when more security is desired (such as multiple admins on the same computer) or if one wants to make ui available from another machine — there is an option to change listening addresss, set that password and enable https. It will be instantly discoverable in the settings for the people who need that.
Personally, I consider myself tech inclined, and I avoid extra passwords whenever possible, always preferring convenience and availability to security, especially when data backup is conserned: if I experience data loss, I don’t need anything to stand between me and my backup, especially extra passwords, that can be lost as well. Ensuring me having access to my data is more important than third party not having access to my data. I understand that some users may be more paranoid — and there are options for them.
TLDR: for most users it will be counterproductive, but for a few that need it — it’s discoverable on the one-pager settings page.
Definitely a fair take and I keep forgetting that I might be using it different than most would in that I’m using the web UI to manage backups on a couple of headless linux servers. In that case I do want to be able to lock it down a bit more since I have to open it to listen to any host on the network (I could likely use some networking to lock that down a bit more).
I guess in my case it was mostly a case of not reading the docs and seeing some old posts in here complaining that there was no password on the UI. Once I realized that had since been rectified, I felt much more comfortable and just had a thought that it might be a good idea to point people to that option if they want it. But reading the docs can also accomplish that.
This isn’t an acceptable option when you want to prevent local, non-admin, users from accessing the interface and tinkering with things - say, on a company PC. The option is definitely a boon.
@twistymcgee I’ll also add… you can’t really do much harm if some kinda malware or remote adversary has access to the interface through localhost - you can’t delete repository or storage files from in there (you can always gauge storage/key locations from duplicacy.json directly anyway).
So while similar apps (thinking Syncthing) will put up a big warning banner, recommending you set up a GUI/API password, the security implications are a bit more real there. And it’s probably to buff security in case you bind the interface to 0.0.0.0 to be more open, and forget to password-protect.
These are good points. I don’t think a big warning is in order, but just some sort of hint that “Hey, you can password protect this UI if you like by going into the settings”. A lot of apps have a bit of an onboarding the first time you use them and I find it helpful to sort of get your bearings. Duplicacy is excellent software, but it can be complex at times. So any help would be a good thing.
1 Like