New security system

The new security system is terrible. Once I was able to change my password and access the web interface (under Windows), but I never understood how I did it. Now (under Linux) I’m just turning over a mountain of manuals, but still can’t figure out what to do.

I used to be able to get my old backups and make new ones in a couple of minutes. Now it’s just a continuous nightmare.

I don’t know what to do. Can you help me get this to work?

“Connection to server was rejected due to invalid authentication”

Duplicati Access Password is a good place to start, if you haven’t come across that one yet.

Possibly you just let the TrayIcon open. This works on Linux too, but only if you use TrayIcon.

Change password with ServerUtil is probably good for systemd, but there are other ways too.

It says that if this is the first run, I will be prompted to create a password. But it doesn’t, unfortunately, it just asks me for a password.

Huh… The command ‘duplicati’ helped.
Thank you. I just panicked. I have very little time and all this fiddling…
Thank you!

You’ve never had Duplicati before? There’s always been a first run setup, but it used to allow no password if you said you were the only user. That leaves a bit of a hole for malware and such…

That’s the TrayIcon, but you need to decide if you want to backup as you, or need a root service, meaning what systemd would run and you would manage with systemctl. That’s separate config password, but jobs are also different. If what you see now is what you want, wonderful. It’s done.

Let me look in AppController.js at “First run setup”

2.0.8.1 has

If your machine is in a multi-user environment (i.e. the machine has more than one account), you need to set a password to prevent other users from accessing data on your account.\nDo you want to set a password now?

2.1.0.2 has

Duplicati needs to be secured with a passphrase and a random passphrase has been generated for you.\nIf you open Duplicati from the tray icon, you do not need a passphrase, but if you plan to open it from another location you need to set a passphrase you know.\nDo you want to set a passphrase now?

Question is whether the version 2 First run setup comes up at first run of version 2 security?

I have been using this programme for over a year. I found it while watching some video on youtube. I have never had any problems with it. It worked like clockwork on both Windows and Linux (Debian + XFCE). And it was very simple.

But now I am just disappointed. There are some new directories in my home directory. The same ones in root.

No, no, I’m sure the programmers have done everything right, they’ve beefed up security, defence, something else, etc. I’m not disappointed in the software, I’m disappointed in myself. I’m just an ordinary user, far from being the smartest, and I’m unlikely to figure it all out. I’ll have to go back to password protected archives (7z) or something like that. I’m sorry.

Anyway - thanks again for your help.

If you have already set a password (in previous versions) you will not be asked to set up a new one.

That indicates that you have started Duplicati both as your regular user, and as the root user (presumably from the service).

There has been no change in the location of settings or the number of files for this update, but I am unsure what you expect.

If you explain what it is that you want, maybe we can guide you better.

If you want to reset the password for Duplicati running as your current user, it should be possible by simply running:

duplicati-server-util change-password

And if you are using the service, you can do:

sudo duplicati-server-util change-password --server-datafolder=/root/.config/Duplicati

My impression is, the arms race between the crooks and the valiant defenders of data integrity is fought on an intellectual level that leaves most of humanity just looking puzzled.

User post below seems to say the answer is no, so question is whether it’d be better to?

I think the belief is that this is how people used to set it up, so make the transition easier?

I don’t know how technically feasible it is, and there’s a question of who might set it first…

I don’t fully understand the question here, but the logic in either version was to have a “first run = true” variable that shows a dialog asking to set a password. If the user clicks either yes or no, it sets “first run = false” so it does not ask again.

The two versions (optional vs mandatory) uses two different variables in the database. Can’t remember the old variable name, but the new is called has-asked-for-password-change.

If the user has set the password, either in the old version or prior to starting the UI the first time, this dialog is not triggered.

is the problem, especially since the ask has changed. The different asks are posted above.

The old question (right or wrong) probably led most people to decline multi-user protection.

The new required password blindsides current users on upgrade. Release notes don’t fix it.

I don’t think there’s any easy way to advise all users about breaking changes, unfortunately.

New password dialog would cover this gap for typical upgraders if it was shown, but it’s not.

Why not lead upgrader through mandatory step? If not, you get a lost user, or support work.

The questions are different yes, but if you declined the multi-user (meaning no password is set), you will get a random password on upgrade and it will show the new question on the first use (same as for new users).

If you accepted the multi-user question and have a password set, you will not see the dialog, because you already have a password set, and there is no point in asking.

I checked the code history and the previous variable is called has-asked-for-password-protection (aka multi-user) and the new one is called has-asked-for-password-change, so your choice on the previous dialog does not matter. What matters is if you already have a password or not.

Do you mean in the initial launch window? Then yes, I agree, and I don’t see how it is not working?

There is currently a deliberately simple installer process (copy in files) so there is not an option to add the question during upgrades.

For the TrayIcon based setups, I think it is working quite well with a random password and a dialog, but it is confusing if people bookmarked the page and do not use the TrayIcon “Open”.

I did consider not setting a random password for the server, but just having the server exit if there is no password, but figured it would be more user friendly with a signin link.
The idea is that backups would run as expected, even if the user does not have a password set up yet.

Maybe that assumption was wrong, and starting with a random password confuses more than it helps.

Is this in all cases? I’m not even sure the old question worked in all cases, but it mattered less.

If it requires a TrayIcon Open, that explains some cases. Got lots of Docker, now some Server.

Yes, at least that is the intention and what I read the code to do.
It looks only to see if the password is autogenerated and if the user has been asked to pick one.

It does require a login first, because an unauthenticated request cannot read any properties, and does not know if the password is autogenerated. Even if we allowed this, we could not allow the user to change the password without being authenticated as that would defeat the purpose of the login.

Two “show new question” answers conflict. First is “in all cases” and second is “not really”:

which sounds like a deadlock where user got locked out and is struggling to get to a login.

Since reading release notes is also tough, one place to inform people may be at login fail.
Server presumably can tell if user got a random password. Maybe GUI can point to docs?

For an upgrader without a password, living with such a risk until set up may be acceptable.
An innocent user might get confused though, and set the password before the admin does.
There’s also the code change question. No point doing big redesign for a dubious solution.

Even if there is someday a fancy installer (e.g. for Windows service), changing all installers probably becomes too much (if even possible), and then there are the people using Docker.

We used to encourage image replacement over autoupdates, and now autoupdater is gone.
Image replacement is sometimes even automated, so user just gets an automated lock-out.

TrayIcon to Windows service is also more troublesome than it was before, due to password.
A --webservice-password seems a risk. ServerUtil password setup doesn’t require that. Limitation with that approach is I think it relies on DB access. TrayIcon may get regular user.

Yes, I think at least we should show more information on the failed login to simplify things.

That is not really trivial to do, as you then have two ways in to the authentication: “not ready” and “ready”. Best practices says not to do it as it is likely to have unwanted complexity in something that is inherently hard to get right. Most users would ignore everything and never set a password if at all possible, so it is not “secure by default”.

Closest thing would be “default password”, but what would happen here is that most users would simply not bother changing the password, which is why it is recomended not to use default passwords either.

Actually, TrayIcon can do the same as ServerUtil. Problem is that you often want Server and TrayIcon to exist in two different user contexts (due to permissions). When you have inter-process communication, especially with different permissions, there is really no secure way without some kind of credential.

For regular users (running just the TrayIcon) I would think the problem is mostly fixed by having a stronger suggestion to re-open from the TrayIcon.

Possibly scrambling context, but let me try anyway

Meant a somewhat daring and maybe hard-to-code more public prompt to change password.

again says the maybe radical change I’m talking about, commenting on concern of a “defeat”.

The idea is not to allow perpetual use without a password, but to not let anyone in without one, possibly with the exception of the TrayIcon SignIn token method which somehow got a bypass.

In an upgrade situation that was previously insecure, it gets secure by force after password set. Admin who does simple post-upgrade test would set a password, but there’s a race condition…

Question is what people are going to be using the Duplicati GUI legitimately besides the admin. Illegitimate users such as attackers would have done attacks on open system before its update.

One would have to think through the use cases…

TrayIcon users get the nicest upgrade path regardless, and better directions can also help them.
I’m talking mostly about the other users, hoping to get some way to make their life similarly easy.

^^^ THIS ^^^ I’ve just upgraded to the latest Duplicati version on my Debian system, which has no system tray. I’ve been caught in the endless “Enter Password” loop for the past 3 hours. Finally came upon this post and was finally able to set a password and log in. Very frustrating!

Just had the same problem with a headless (no tray icon) Debian install.
The installer actually gives you the login key, but it runs off-screen in my SSH client (MobaXterm) so I couldn’t use it. By the time I had worked out what was wrong and done
journalctl --unit=duplicati > output.txt
to get the full token it had expired.
Fixed it by temporarily adding --webservice-password=xxxx to the config.

1 Like

Thanks for reporting your experience.
For others seeing this, you can also restart the service to have it generate a new token.
It will keep doing this until you have provided a new password (either from CLI or the UI).

I have updated the documentation to suggest using:

sudo journalctl --unit=duplicati | less

And added a note that journalctl caps the long line. Sadly it needs to be fairly long to securely emit the token.

1 Like