KeepassXC security and single backend for all Qubes? (and healthy password management practices)

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 :confused:

ok if no one else is interested, I give up: too much effort for something that is just for my personal use.

2 Likes

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?

I wish I could have in-app ACL-like control which passwords to share, but it would require maintaining our fork of KeepassXC.

I’m interested: +vote :slight_smile:

1 Like

Ok will give a few more shots. Apparently it is some socket forwarding issue: locally in one qube everything works.

3 Likes

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 !

Anyone can imagine an ACL system / shareability flags that would make sense beyond Qubes?

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 :slight_smile:

Either this. Or, as a dirty hack, implement an entry/folder flag “visible via browser extension”.

The flag sure can do for a PoC, but that’s not very fine-grained for an ACL system :slight_smile:

Yes. But do we actually need more? Because more sophistication means more management compexity.

True. Let’s dig into what we really need.

Today, when a connected browser/whatever requests access to a website creds, KeepassXC (2.3.4 in debian-10) shows a window with the plugin name (“KeepassXC-Browser” and the website, but not the connector name (eg. “work/firefox”). If it was showing this (more recent versions maybe do ?) it could even be sufficient for my own use. But even this lack of label can be mitigated by an “ask” qrexec policy.

So do we really just need to setup a socket proxy ?

lsof on it reveals several UNIX sockets but no obvious way to know what’s what. I’d say looking into a small client like keepassxc-proxy-client · PyPI may be the best way to find out.

The latter wants to use $XDG_RUNTIME_DIR/org.keepassxc.KeePassXC.BrowserServer, but that one does not exist here. Other sources mention $XDG_RUNTIME_DIR/kpxc_server which does exist here.

BTW, there was another thread on this subject some time ago - not about KeepassXC itself though:

Ok guys I got it working. May need a bit more debugging but that’s it.

Speaking on password sharing control, I think if we want to modify KeepassXC to make some passwords shareable to the browser while some are to be local-only, tags or groups are apparently the proper way to control that because we need to maintain compatibility with other clients. But need to patch KeepassX for that anyway.

That’s nice! Now I have:
single gpg backend for all qubes thanks to split-gpg
single smartcard backend
single u2f backend
single password manager

I would like to share how im using keepass.
I have a local-admin appvm, which syncs my keepassdb via syncthing with my NAS and phone, all local /vpn. And a second keepassdb local, in vault. No net.

Only using dispvms for online activities.

would you feel comfortable if the “shared” keepass db would be accessible via browser extension?

no never. No browser would ever be allowed to touch my kdb

1 Like

Congrats. :partying_face: Are you going to share a howto for this? :)~

2 Likes