Password managers in Mullvad Browser

[ruihildt]

There's a strong recommendation to use an external password manager, but the browser extensions for these don't work properly (at least in the case of 1password). What's the recommended way to integrate an external password manager with Mullvad Browser?

[ruihildt]

Would you consider implementing the Bitwarden password manager, natively into your browser? I know you can install it manually.

[rusticadam]

Bitwarden or KeepassXC would be good idea. +1 for this.

[riffer33]

I'm using the Bitwarden extension (Linux) without any issue, but it would be preferable from the point of fingerprinting if this was included with the browser, or that Mullvad worked with the Bitwarden App (This is a Bitwarden issue I would assume). Not a big deal but it would be a nice addition.

[jakob11git]

Proton Pass will be open-source, work completely stand-alone in the browser as extension, and is European like Mullvad. But instead of bundling something from one specific company it might be better to just give some examples or link to an informative blog post about the topic.

[AutonomousCat]

I can confirm as a Windows 10 user, that Bitwarden has no problems running (installed from Firefox extensions site).

[kennedy]

EDIT: No longer an issue on macOS, but still for windows.

1Password has not vetted the mullvad browser, blocking the browser extension from connecting to host 1password app.

To temporarily override the restriction, in the 1Password App -> Settings -> Labs, enable "Enable custom browser support". Then go to 1Password App -> Settings -> Browser, add mullvad browser.

This will allow the extension to communicate.

---

bump. I would like to petition further research for 1password support.

Compared to firefox, 1password's extension establishes communication with the host computer's 1password application. On macOS/windows, it would allow users to unlock the extension with onboard bio-metrics.

Currently, 1password's extension on mullvad can not communicate with host computer's 1password application. Not being able to unlock my password manager easily with bio-metrics with the browsing session oftenly resetting, makes using mullvad fatiguing.

I can definitely appreciate the security stance, but I have enabled allowed remember browsing history to reduce the amount of re-logging in I have to do. But purely allowing bio-metric unlocking would provide great quality of life improvement.

[felschr]

The latest update of the Bitwarden browser extension introduces support for Passkeys. The way it's implemented is basically a polyfill for WebAuthn. Specifically it sets navigator.credentials, which otherwise doesn't exist in Mullvad Browser due to it's lack of WebAuthn support (see #53).

I haven't looked much into other areas of the Bitwarden extension. It might've already been fingerprintable, but my guess is that it would only be fingerprintable when it render some UI elements on the website, e.g. the bar on the top that asks whether the user wants to save/update the password they just used to register/login somewhere. If that's the case, that would be less of a concern since these websites are more trusted. The new passkey support changes the fingerprint even without actively using Bitwarden in some manner, though, so it's a bigger concern.

Anyway, Bitwarden's Passkey support doesn't even properly work in Mullvad Browser, likely due to missing WebAuthn support (#53), and there doesn't seem to be a way to disable Passkey support in the extension.

[Thorin-Oakenpants]

@felschr I don't have a bitwarden account (and not going to set one up), but I added the ext (and allowed in pb mode) in MB and AFAICT it doesn't modify the fingerprint (edit: on all sites)

• probably because I have no account set up
• maybe it only modifies the API/dom-elements for sites it is used on?

You can also test the navigator object: anything reported after constructor is a dead giveaway - e.g. in the console you can type

console.log(Object.keys(Object.getOwnPropertyDescriptors(Navigator.prototype)))

So even if the API was enabled for all MB users, navigator.credentials would still be revealed as tampered with

If this is only exposed on sites with saved passwords, then it's not a super viable tracking feature - that's not to say it can't be used to link accounts

[Thorin-Oakenpants]

Anyway, Bitwarden's Passkey support doesn't even properly work in Mullvad Browser, likely due to missing WebAuthn support

passkeys aren't supported in ESR115

• https://connect.mozilla.org/t5/ideas/support-webauthn-passkeys/idc-p/30123/highlight/true#M17028
• FF121 1853230 added to macOS (work in progress)
• password meta 1792433

[Thorin-Oakenpants]

rui: so to check navigator.credentials is altered on all sites or only on those which you have a saved password, and maybe it is only on the login page (IDK) you would just type navigator.credentials into the console and hit enter

TB.MB should be undefined

If it's modified you will get (something) like

[ruihildt]

TB.MB should be undefined

It is not undefined with the extensions being just installed, without even login in.

Next question is, is it the same navigator.credentials as the default one when the Firefox integrated password manager is enabled?

[Thorin-Oakenpants]

IDK. If the API is enabled, bitwarden might use that and then it should/could be the same - but if it's a polyfill then no

[Thorin-Oakenpants]

try

• https://arkenfox.github.io/TZP/tests/functionprops.html
• select All
• search for cred (uncheck whole words)

I see 4 in FF with the API

                               Credential: 18fc7e88 (3)
[
id, type, constructor
]                     CredentialsContainer: b4c4ab89 (5)
[
get, create, store, preventSilentAccess, constructor
]
                       IdentityCredential: 6e5ee7aa (2)
[
token, constructor
]
                     PublicKeyCredential: d98065ba (6)
[
getClientExtensionResults, toJSON, rawId, response, authenticatorAttachment, constructor
]

on MB without the API I see

                               Credential: 18fc7e88 (3)
                     CredentialsContainer: b4c4ab89 (5)

so I think the last two IdentityCredential and PublicKeyCredentia are what matters

of course this isn't a super deep dive. If you use TZP you could do a summary or full FP compare (copy the JSONs in the popup overlays and do a diff) to see what pops out (and TZP is a WiP, there's a lot more that we could do to expose prototype lies from extensions)