Vorta: Passphrase handling improvements

[apollo13]

Is your feature request related to a problem? Please describe.
While keyrings are nice and well, it would be even safer if the passphrase weren't stored anywhere at all.

Describe the solution you'd like
An option to prevent passphrase storage in the keyring, a backup should then prompt for the passphrase.

[Hofer-Julian]

Sounds reasonable to me.
I'd be willing to review a pull request for that feature, if you want to try it.

[apollo13]

Sweet, I'll give it a shot.

[Ramblurr]

I'd like to see this issue tackled not because I don't want the passphrase stored at all, but because my Vorta backups broke when I disabled the gnome keyring. I don't explicitly use the gnome-keyring-daemon, and I recently switched to using KeePassXC's new feature that provides freedesktop.org secret service integration. This broke my backups because Vorta could not get the repo pass from the keyring.

A few thoughts here:

The Vorta error merely said the passphrase was wrong, which confused me. The UI should tell me that the keyring isn't available. I happen to be a technical user, so when I happened upon this line in the source I knew exactly what had happened.

There is no way for me to change the backing keyring, I had to unlink my repo and re-add it. I don't suppose this is a common enough usecase to require a feature addition for, but at least a good error message telling the user what the state of things is (e.g., Your repo passphrase was stored in the system keyring, which is no longer available. Try unlinking and re-adding your repo.) would be more user friendly.

Maybe there should be an option to force storage in the settings database?

[sudwhiwdh]

Nice idea! My system doesn't have to know my password, right? Can you please implement this feature? Or does the solution have any disadvantages?

@apollo13 Could you still imagine to work on it?

[m3nu]

Borg needs the password for various background operations. Entering it every time will be annoying. Scheduled backups will also stop working. I don't see how this would be user-friendly.

I'd prefer to make the handling of existing password backends better instead and maybe support a passphrase command.

[apollo13]

@apollo13 Could you still imagine to work on it?

I stopped using vorta once I realized that it falls back to plain text storage without any warning.

[m3nu]

I realize that some early decisions I made related to password handling aren't appropriate for everyone or for a more widely used app. Based on the feedback here, I suggest the following additions (sorted from easy to hard, with some depending on previous ones):

• [ ] Display which backend is used for password storage. (Improve transparency)
• [ ] Add a password dialog that can trigger from the detached Borg thread whenever there is an issue finding a password (Addresses migrating settings or the user editing the system password store)
• [ ] New repos: validate password 2x to prevent typos.
• [ ] Checkbox to save or don't save password to disk. If not selected, the password is only saved in memory while the app is open.
• [ ] When saving the password in Sqlite, do a very basic obfuscation before saving it. So someone would at least need to read the source code before getting the plain text password.

Would this address everything?

[sudwhiwdh]

Checkbox to save or don't save password to disk. If not selected, the password is only saved in memory while the app is open.

Thanks, I think this is the way KeepassXC goes (to safe it in memory, while the app is open). It works very well and solves my use case.

When saving the password in Sqlite, do a very basic transformation before saving it. So someone would at least need to read the source code before getting the plain text password.

Would it be possible to store the password encrypted or hashed in the database? I have the feeling that people who are looking for it will already know how to search the source code.

Display which backend is used for password storage. (Improve transparency)

Question here: Do you support freedesktop.org Secret Service API as well?
https://specifications.freedesktop.org/secret-service/latest/index.html

[m3nu]

Would it be possible to store the password encrypted or hashed in the database? I have the feeling that people who are looking for it will already know how to search the source code.

That's a common problem most desktop apps have. While I'm happy to encrypt all you like, the key needs to come from somewhere. You just shift the issue.

Question here: Do you support freedesktop.org Secret Service API as well?
https://specifications.freedesktop.org/secret-service/latest/index.html

Yes, we already use that to save passwords, if it's avail.

[sudwhiwdh]

That's a common problem most desktop apps have. While I'm happy to encrypt all you like, the key needs to come from somewhere. You just shift the issue.

How does a password manager like KeepassXC solve this? My master password for the database shouldn't be stored there unencrypted and in plain text on my system, should it?

[m3nu]

The master password is kept in memory. Same as what I suggested above. You probably enter it after restarting? I do. Same as for a system keychain (often uses the main user password).

Attaching Vorta to the password manager or system keychain makes sense. Entering the password every time you start Vorta? Probably not so great. Just imagine if every app would do that.

[m3nu]

If many people use KeepassXC, why not make a backend for it? Our password storage interface is quite flexible actually.

[sudwhiwdh]

Entering the password every time you start Vorta? Probably not so great. Just imagine if every app would do that.

How many times a day do I start a backup app like Vorta? That's pretty rare compared to other Apps. Maybe I do it not even every day.

KeepassXC has the following security checkbox options: "Lock databases when session is locked or lid is closed" and "Lock databases after inactivity of n seconds".
-> I find both settings reasonable from a safety point of view. In both cases this means that I as a user will be happy to re-enter my password to unlock my database again.

If many people use KeepassXC, why not make a backend for it?

I don't know anything about that. How much work does it take?

So what do you suggest that would be an improvement for Vorta to not have to store the password in plain text in the SQLite database in the future?

[m3nu]

Already summarized my suggestions above. In addition:

• [ ] Add KeepassXC backend, if available (not much work, if there is some CLI or library already)

We will still store the password in SQLite if nothing else is available. I don't know another option and I don't see a security trade-off either: If a bad guy can read your local files, they don't need the backup. This was discussed before for other apps and we don't need to repeat it here.

[sudwhiwdh]

Thanks, I am happy with the mentioned improvements!

[Ramblurr]

@m3nu KeepassXC supports secretservice. It can act as a secretservice backend.

My Vorta is already storing the borg passphrase in my KeepassXC database, via secretservice!

There's no need to build from the ground up something new, rather I would like more transparency features:

• [ ] Handle the edge case when the secret service backend changes (from gnome keyring to keepassxc for example). Vorta should realize the password it thought was there, is no longer there, and prompt the user to re-enter it

• [ ] Optionally allow the user to enter the lookup path to the passphrase in the secret service backend. That way I can point Vorta directly to the already existing entry in my Keepassxc db, rather than vorta creating a new one.

[m3nu]

Agreed on item 1. This is already contained in the tasks above.

For item 2, I don't know enough about SecretService. Maybe something for the docs?

[samuel-w]

I partially implemented the suggestions in https://github.com/borgbase/vorta/issues/385#issuecomment-635060484. in the above PR.
I left out:

1. Hard to implement due to circular dependencies, and depends on a GUI for new password entry. If someone needs security, they should use a password manager of which we have backends for already.
2. Obfuscation is not recommended for passwords, and if someone has access to your DB, they also have access to your home directory, and could just plant a keylogger. There are more than enough keyring backends that using the DB should only be used for the test cases.

[samuel-w]

As an alternative to

Checkbox to save or don't save password to disk. If not selected, the password is only saved in memory while the app is open.

Could we just cache the password in memory so that the password manager doesn't have to be constantly unlocked?