Since I am trying to master qrexec and make split-everything-socketable, I found it relatively easy to make a split-KeepassXC-browser configuration, where multiple browser instances in different Qubes may access a single KeepassXC backend. Are there any objections why it would not be recommended and I should stick to copying all the passwords manually (ugh)? I can disable it for most “dangerous” qubes anyway I also wonder if locking/unlocking the password database can be controlled via socket so I can lock it from the client qube as a security pre-caution.
Typically, my approach is to keep some “common” service passwords in KeepassXC, while more sensitive, project-specific passwords reside in specific VMs built-in password managers (like FF without sync or Chromium bound to a separate Google account with advanced protection turned on). Is there any space for improvement? Can you share how you do it?
The reason for a network separated KeePass(XC) database is to defend your secrects agains a normal VM compromise. So there can be my most valuable secrects.
And if you keep that rule that you never copy in, but only copy out. It can be safe until util your dom0 can hold it.
allowing the browsers to search in that database is a huge compromise - at least for me. So I would never ever do such thing.
for me the less valuable passwords, like forums. and social media are saved in the VM using it, because If tha VM ever compromised, the accounts used there is already ‘lost’…
…debatable. If a qube is compromised, then everything depends on the attack window time-wise. And for less valuable passwords it would make sense to make them available to DVMs, as well.
sure! That’s why we talking about a “threath model”.
Amd that’s surely differs for every user out there. → means there is no best defaults for everyone.
I rethinked my password approach, re-classified all of them by two parameters: availability and security.
For low availability and low security, I stick to keeping them in respective qubes (like, passwords for non-essential services)
For low availability and high security (like, trusted communication, financial systems etc) I keep them in offline KeepassXC qube.
For high availability and low security (like, forums, non-essential services and e-commerce sites where I do not store payment data server-side) – I do not really care about but like to be able to log in from anywhere, I have another KeepassXC database which I sync to Dropbox and will make this split configuration so I could access it from any qube.
For high availability and high security… well, there should be none, because those two requirements do not mix well, I’d better rely on a hardware token thus reducing the password security to “low”.
UPD: however, turns out that it is somewhat tricky! the documentation is out of date and I still cannot figure out how to find the proper socket name to communicate to keepassXC!
I continued my experiments and it is acting weird. When I have one browser connected with keepassxc-proxy instance, I cannot connect a subsequent one, it says “cannot encrypt message” or whatever. Anyone have an idea what happens there? keepassxc people from the Matrix dev channel say it is not the way it is supposed to act
For me, unfortunately not. Leave your computer unattended while on (and if you don’t have lvm, even off), and there you go. For me it’s not only about online compromising. Remember Snowden in that documentary covering himself with a blanket while typing password in a hotel room? You never know where the drones are, hahaha. Or am I missing something? (I was referred to this topic to get an idea, but it turned out I got a what-not idea).
I still don’t get it why KeePass from the vault-vm, locked with master password (which is pasted by drag and drop into KeePass from the external virtual keyboard that provides hidden mouse and hover entry option for master password typing), to share passwords across qubes (“these password can go to this qube, these ones to that one qube, etc”…) with what ever key-stroke combination+mouseclick+2_channel_auto-type_obfuscation during pasting is bad idea?
With a clear use-case, upstream devs could be interested in merging such a feature, “maintaining a fork” is really the last resort when one depends on non-upstreamable patches !
KeepassXC seems to keep connections for each connected browser, although they only appear as such in the plugin’s configuration, and not in KeepassXC’s own Settings panel. Assuming it’s working like I guess, I thought that those individual connections could be the objects on which permissions could be
managed.
That’s a big “if” but from here it seems plausible. If it is confirmed, it seems it would require to start with making those connections apparent, and probably allow to revoke a connection. I’d suggest anyway to
approach the KeepassXC devs early anyway
I also wonder if locking/unlocking the password database can be controlled via socket so I can lock it from the client qube as a security pre-caution.
