mullvad / mullvad-browser

Privacy-focused browser for Linux, macOS and Windows. Made in collaboration between @torproject and @mullvad
https://mullvad.net/browser
1.33k stars 25 forks source link

Password managers in Mullvad Browser #74

Open ruihildt opened 1 year ago

ruihildt commented 1 year ago

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 commented 1 year ago

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

rusticadam commented 1 year ago

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

riffer33 commented 1 year ago

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.

salixh5 commented 1 year ago

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 commented 1 year ago

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

kennedy commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@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)

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 commented 1 year ago

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

Thorin-Oakenpants commented 8 months ago

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

TB-MB

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

tada

ruihildt commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

try

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)

metametapod commented 2 months ago

I am not able to use the 1Password extension with Mullvad Browser on macOS, even with the "Enable custom browser support" setting enabled. It shows the following error:

Screenshot 2024-09-06 at 14 27 18

Can’t store local data

You'll need to turn off "Never remember history" and "Always use private browsing mode" to use 1Password."

However, the passff extension works as expected, so as a workaround I've been mirroring select items from 1Password locally using pass:

op read://Personal/<itemid>/password' | pass insert -e mullvad/site/username

Note: The system wide autofill feature with 1Password (Command-\) does work with the above setting enabled, just not the browser extension.

randshell commented 2 weeks ago

Hi everyone!

I'd like to add that, when it comes to Passkeys and Bitwarden, the fingerprinting is actually quite straightforward on the current version. This is because the fido2 script gets injected into every page using the unique UUID of the extension's install. For example:

<script src="moz-extension://89a2c3a2-eea9-413c-802a-7b07f764aa2a/content/fido2-page-script.js" type="text/plain">

The only way to avoid this would be to disable Passkey support manually, which can be done by going to Settings > Notifications > Ask to save and use passkeys and unchecking the option.

Thorin-Oakenpants commented 2 weeks ago

unless I'm missing something ... the extension id exposed to web-content in gecko is randomized per profile (technically per install)

randshell commented 2 weeks ago

Yes, as far as I saw too, the extension's UUID is unique per install and hence my concern. Rather than (or on top of) the usual fingerptinting techniques, the websites could just grab the Bitwarden's UUID and recognize the visits of that specific user. I see it like browsing the Internet by advertising to each page an identifier that is unique to you.

Thorin-Oakenpants commented 2 weeks ago

Sorry, not with it today. So right ... a listener should be able to grab this info? (my brain is overheated from too much work)

Where's the issues at these extension's repos/sites? Where is the uproar, because it's very serious if true? By that I mean it's sooooo bad (and amateur and these perps have been build web extensions for a long time, around security/privacy) it surely can't be right. IDK, just asking

ruihildt commented 2 weeks ago

I can confirm Bitwarden extension Internal UUID is injected in the DOM to load the script.

ruihildt commented 2 weeks ago

Opened: https://github.com/bitwarden/clients/issues/11875