Hide Mail Password for "send-mail"-feature

I am using the “send-mail”-feature to send a mail to a user, if something fails. One thing I don’t like is, that I have to paste the password in clear-text.
The problem is, I install other users in our group duplicati for their backups on a network drive. They should have the possibility to look at the duplicati GUI in the browser, via the Tray Icon. I don’t give them the password. For sending mails I am using an extra Mail-Account for this porpuse. If they have accsess to the GUI, they can read the password for this Mail-Account there. I don’t want this.
The other possibility would be, they would use their Mail-Account for sending their mail. But then I could see their password, which is also linked to several important things. I don’t want this either.

So is there any possibility to hide the mail-password? Or any other idea to solve this problem?

Thanks in advance!

This is a bit confusing, but it can be a tough balancing act trying to give everyone the right level of access.

This seems to say they should have GUI access, which currently is all or none, but you are blocking them.

possibly is the reason for blocking them. Is this because mail sending password is reused for other things?

is the reverse problem, with you seeing theirs, instead of them seeing your password used for mail sends?

First, anybody who has access to the Duplicati system can possibly get the configuration, and GUI’s hiding doesn’t prevent that. Putting something like * for characters does prevent shoulder-surfers from seeing the possibly-but-hopefully-not-memorable secrets there, but GUI allows other ways to see entire configuration.

Password on the GUI avoids using GUI to see things, but that begs the question of who gets the password. Bypassing the GUI is also possible. How much are you willing to trust the users and vice versa? Usually an administrator (you in this case?) is trusted and enjoys wide access. Users (especially unknown) might not.

Who does what generally? Do users decide what to back up, do their own restores, etc.? If not, who does?

Thank you for your answers!

Some Info to make the situation clearer:

  • Yes I am the admin, and of course the users must trust me. But still I am not on the admin level to see the Password for their Mail-address, as this is an account linked to many services.
  • The Mail-Adress from “me” that I could use instead, is also linked to some other accounts. The users could login to this mail account, writing mails from there etc…
  • The users should do their own backups and their own restores.

If hiding the mail-password is not possible, then I must overthink the system.

Way 1:
One way would be, that I don’t gibe the users accsess to the GUI. This would mean, they have to ask me, if they want to change their backups or if they want to do restores. I could use mail-notifications to their account, so that they see, if something went wrong.

Way 2:
I give them access to the GUI, but then I have to deactivate the mail-function.

Way 3:
I need a mail-address that is not so important. Then it might be not a problem, if the users can see and use this mail-address.

Am I missing anything? Is there the possibility to only show the hash of the password for the mail-account? Or using some key-files?

This seems like a tangled knot of desired separation running into password reuse across many services.

which means you could probably get their “linked to many services” password, but you’re not authorized. Question also arises of who typed in their password originally. You’d like it to be the user if it can’t be you.

Way 1 also probably puts more work on you, e.g. for file restore. Are you authorized to access their files?

Way 2 is presumably where mail uses your chosen password. There are other ways to get reporting out.

Reporting options is the base, and we’re talking mail, but http is also possible using free or paid services.

Duplicati Monitoring is a third party donation supported service.
Introducing the Duplicati Portal: Your New Hub for Cloud-Based Backup Monitoring and Management
is an emerging freemium service from Duplicati Inc. that seems ambitious. I’m not sure if does email yet.

Way 3 might also be implemented with an email server that doesn’t need a login. This was once common with corporate email servers that would accept emails from the company network.Possibly this is less so currently, or perhaps your users are remote (which raises other questions if you must remote administer).

Or if no login is not possible, one with an email login where credentials are email-only might be acceptable. Typically email servers offer some logging, I believe, so anyone abusing the emailing can maybe be found.

How would this help anybody or anything? Mail service may want a password. User likely won’t know hash.

Simplest way is to not email. Use some http notification plus software. Some people even write their own.

Example Scripts shows how options can be set from a script, e.g. from a file where user types password, however the trick would be how to securely protect the password from being too easily seen, even by you.

If you want to explore other ways to submit email, please contact your email server admin. We don’t know.

Does user have administrator privileges on their computer? Which system account will Duplicati be using?

Is this an Active Directory domain? That might have other ways, but you’d need to talk to that administrator.

Basically, even without Duplicati, is there a way on a system to keep them out of your stuff and vice versa?

1 Like

Thank you very much. Notification via http sound quite intersting. Also Duplicati Monitoring looks great.

I will try out different szenarios.

Thank you very much for your helpfull ideas and advices!

1 Like

I think I understand what it is that you would like to achieve. The users should be able to access some parts of the application, but not others.

Hiding information in the UI is one way to achieve this, but since the system itself needs access to these credentials unencrypted, they cannot be fully inaccessible. The user could perhaps open the database and extract the information from there.

The partial access is not something that is implemented in the current UI, but it has been something I have been considering to implement from the beginning, so there are small pieces in place.

For your immediate needs, I would suggest different credentials for each machine, to at least be able to control how much damage a set of leaked credentials can cause.