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

[arkenoi]

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

[yann]

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 ?

@arkenoi

I still cannot figure out how to find the proper socket name to communicate to keepassXC!

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.

[yann]

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

Survey/Poll: split-pass

Inspired by split-GPG, split-pass would be a split-password manager. Let’s say your adversary has the power to pwn your password manager: boo! split-pass would make it far more difficult - split-pass would make passwords truly multifactor. How: you could store a load of garbage in keepass, and have a dedicated VM or external device to turn it not into garbage - hence split-pass. This is good for really very sensitive info and those who need deniability in hostile environments. As this is ra…

[arkenoi]

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

[0bit]

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.

[arkenoi]

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

[0bit]

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

[grey_olli]

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

[ppc]

@grey_olli

Are you going to share a howto for this?

Password management: now HOWTO

Now I managed to make the whole thing together. If you “keep all your passwords strictly offline”, just stop reading. For the rest of us. First, I divided the passwords to 3 categories: “high security”. The security requirement is defining, so we need to sacrifice some availability here. “domain-specific”. These passwords are needed within a specific context and typically may reside there. “accessible”. For these passwords, accessibility requirements are more important than security. JFYI, …