Interest and feedback on a clipboard-based, "universal" split password manager?

General Discussion
1

Tl; dr
I’d like to compartmentalize my Bitwarden password manager vault with a “split-bitwarden” setup. The Bitwarden browser extension, however, does not communicate with a local version of the vault and thus cannot access a split vault in the traditional, socket-based “Split-<service>” method.

Instead of relying on software in a Client VM to send requests to a Vault VM, what if the user initiated requests to the vault from dom0 (or even from the Vault VM) and the requested vault data was put into the Client VM’s clipboard (using e.g. qvm-run-vm)? At this point the user could hit Ctrl-V to paste the data (this could even be automated with xdotool).

Motivation:

  1. I use the Bitwarden password manager and want to stop using the Bitwarden browser extension to access my vault (to avoid typing in master password and to reduce browser fingerprint).
  2. When I need login information in an environment without the browser extension, such as Tor Browser, I have to manually copy the data from the vault into that VM, which is cumbersome.

Proposal:
Create a “Split-Bitwarden” password manager system which compartmentalizes the Bitwarden vault into a Vault VM and gives Client VMs limited access to the vault.

Unlike gpg or keepassxc, the Bitwarden browser extension does not seem to communicate with any local vault, which means directing the extension’s requests through a socket to a vault in the Vault VM is not possible (AFAIK). Thus, short of creating an extension which could communicate with a split vault, some other method of access is needed.

dom0 will send a request to the Vault VM with, at a minimum, the name of a password manager, the name of the Client VM, an account identifier for the data being requested (e.g. name of account entry in the vault), and the type of data being requested (e.g. username, password, totp). The Vault VM will query the password manager for the piece of data from the specified account identifier. The Vault VM will then run a command like qvm-run-vm <ClientVM> "echo <password> | xclip -sel clipboard", which puts that password in the clipboard of the Client VM. The user then pastes the password at their convenience.

Benefits:

  1. This setup would be extensible to any password manager accessible via the shell or via an API (including but not limited to Bitwarden, pass, and KeepassXC).
  2. Could provide fine-grained access control over which pieces of vault data can be sent to which Client VMs (using a user-written configuration file).
  3. It would eliminate the possibility of a compromised Client VM exploiting “a hypothetical bug in the GPG backend” and gaining control of the vault (see split-gpg docs).
  4. Eliminates reliance on socket-based split-password manager systems, which are harder to implement, install, and (possibly) maintain.

Drawbacks:

  1. Users have to initiate requests, although this can easily be done with keybindings and interactive menus like dmenu. (Of course, normal e.g. KeepassXC users still have to “initiate” their requests by manually interacting with the vault).
  2. Results in vault data being stored in the clipboard of a potentially compromised Client VM, which may (?) be less secure than sending that password through a socket over qrexec.

Does this sound like a useful project? Are there other drawbacks, particularly security drawbacks, which I am not considering?

I’m halfway done with a proof-of-concept and will continue developing it if there appear to be no major downsides or oversights.

2 Likes
2

A community guide like this will be useful, even if just one person in the world appreciates it.

2 Likes
3

Transferring the password is initiated from dom0. This is problematic, because dom0 has all the power. This gives away the chance to restrict which password can be shared where. Instead, the user has to be cautious not to give away passwords in the wrong context.

I ended up here, because I am considering starting something like Split-GPG for passwords. The idea goes like this:

  • A Qubes RPC service is installed in the vault. This service is pluggable. You can hook in the password manager of your choice.
  • The qubes where you want to use passwords, have a tool installed that talks to that Qubes RPC service. It allows listing available passwords and retrieve username, password, and, if available, totp tokens.
  • Policies in dom0 control, which qube is allowed to access which passwords. This is done through service arguments. The arguments then can be used on the RPC service side, to decide which passwords will be allowed or not. For example by restricting access to passwords in a specific password store, or passwords with a given tag, or whet ever else suits your needs. The point is, you can have one single password store, but qubes can only access a subset of those passwords based on policies.
  • This can then be accompanied by a browser plugin, that also talking to that RPC service.