Qubes OS browser extension for passwords and passkeys

[DemiMarie]

How to file a helpful issue

The problem you're addressing (if any)

Password management in Qubes OS is non-trivial and not (inherently) phishing-resistant. Browsers on Qubes OS do not support passkeys.

The solution you'd like

Qubes OS should provide a browser extension that implements password and passkey management. The browser extension would use Native Messaging to communicate with a daemon (written in Python or Rust) that in turn communicates with the vault VM over qrexec. Passkeys can be stored in software (default) or a hardware token (needed for attestation).

The value to a user, and who that user might be

All users willl benefit from better password management and from native passkey support.

Completion criteria checklist

(This section is for developer use only. Please do not modify it.)

[ben-grande]

Demi, isn't this issue two things, the server side and the client side? Shouldn't they be two issues to not limit the server side and client side implementation to one design?

The title specifies the client implementation:

Qubes OS browser extension for passwords and passkeys

But that would limit to only configured browses to use that, an not other browsers or local applications. That is limiting the usage of this tool. Can it be not specific to browsers? Or are you talking about a specific key that is used only in browsers such as Android device being used as a security key?

[DemiMarie]

A better approach would be the following:

1. A cross-VM implementation of proposed XDG Credentials Portal implementation.
2. A cross-VM password manager interface:
   • An XDG portal for passwords (Add password portal flatpak/xdg-desktop-portal#311), which is not specific to Qubes OS.
   • A cross-VM implementation of this portal, which is Qubes OS-specific.
3. Browser support for 1 and 2, either by native support in browsers or a browser extension and native messaging host. This part is not specific to Qubes OS at all.
4. A pure-software passkey implementation.

It would be simpler to implement 3 directly in terms of a Qubes OS-specific interface, but this would not integrate with or advance the broader Linux desktop ecosystem. I would prefer for Qubes OS to not do everything itself.

@marmarek: Is it okay to use D-Bus as a cross-VM wire protocol, if the D-Bus server is written in a memory-safe language?

[marmarek]

@marmarek: Is it okay to use D-Bus as a cross-VM wire protocol, if the D-Bus server is written in a memory-safe language?

No.

[DemiMarie]

@marmarek: Is it okay to use D-Bus as a cross-VM wire protocol, if the D-Bus server is written in a memory-safe language?

No.

Is this because of parsing complexity? To clarify, this would be a peer-to-peer connection, without a broker involved.

[marmarek]

Is this because of parsing complexity? To clarify, this would be a peer-to-peer connection, without a broker involved.

That is one reason, yes. But also audit complexity, hard to write strict policy and many more. For password manager like service it really doesn't need to be this complex, you more or less need a request with some service id (website URL?) and response with username+password.

[andrewdavidwong]

A better approach would be the following:

1. A cross-VM implementation of proposed XDG Credentials Portal implementation.

2. A cross-VM password manager interface:

   • An XDG portal for passwords (Add password portal flatpak/xdg-desktop-portal#311), which is not specific to Qubes OS.
   • A cross-VM implementation of this portal, which is Qubes OS-specific.

3. Browser support for 1 and 2, either by native support in browsers or a browser extension and native messaging host. This part is not specific to Qubes OS at all.

4. A pure-software passkey implementation.

Sounds like it might make sense to turn this into a GitHub project and create separate issues for each part.