Browser extension that requests only specified login item from other clients

Hello, I am trying Bitwarden and it’s so far so good except concerning about browser extension. I don’t want the browser extension to download and decrypt all entire vaults. In stead, I want it to send request for specified login item, e.g. for URL of current site, to other clients where I can confirm and select a login item. Is this a thing in Bitwarden?


Edit:

Because I don’t want to expose ALL decrypted(or decryptable data and master password) in browser’s memory. Web browsers have huge complexity. More things one have to trust, more risks one is facing. This feature would be trade off between convenience and security. It doesn’t mean that one can not-to-trust browsers, but can reduce affected range if disaster comes.

Found some related discuss:

https://www.reddit.com/r/Bitwarden/comments/170y2dq/security_and_privacy_implications_of_browser/

@witdarben Welcome to the forum!

Bitwarden is not designed to work the way you are suggesting.

With the exception of a few advanced features that are not relevant to this discussion, each client app (e.g., browser extension, Desktop app, mobile app, Web Vault, etc.) works independently of any others that are running. Each app instance that has been authenticated (i.e., apps that are logged in) has its own locally cached copy of the vault, which is synced with a cloud database when changes are made. Although the cached vault data are stored in the local hard drive, this vault cache is encrypted.

The vault cache is only decrypted when your browser extension (or any other client app) is unlocked, but the decrypted vault contents are only stored in volatile memory on your device. The decrypted vault contents are cleared from memory whenever the client app is locked.

Although the cached vault data are stored in the local hard drive, this vault cache is encrypted.

But it is decryptable IIUC. (Edit: with cached master password(or hash of it?) in memory)

To decrypt the locally cached vault data, a 256-bit encryption key is needed. An AES-encrypted copy of this key is stored with the cached vault data, but this encrypted key is useless to an attacker unless it is itself decrypted. The browser extension (or any other client app) derives a 256-bit master key by hashing and stretching the master password (using the key derivation function, or KDF), and this derived key is used to decipher the vault encryption key (which is then used to decrypt the cached vault). Therefore, you need to supply your master password to unlock (decrypt) your locally cached vault. As long as you have a unique, strong master password that you keep confidential, you are the only one who can decrypt your vault data.

Thank you for this explanation. I’m concerning about unlocked status. Read edited description and links above.

Your first link is to a Reddit thread in which the OP is running some sketchy browser extensions that they don’t fully trust.

The second link you posted is about some old bugs that were found in Lastpass (no surprise) and 1Password. Incidentally, the 1Password bug involved intercepting traffic between the browser extension and the desktop app, exactly the architecture that you are proposing.

The bottom line is that if you allow sketchy processes or malware to run on your system, then there is nothing that any password manager can do to protect the contents of your password vault.

On the other hand, if you keep your devices free of malware, then no website that you visit is going to be able to access the contents of your device memory. Likewise, if you control access to your devices, lock your vault when not in use, refrain from disabling Bitwarden’s built-in security features, and have an uncrackable master password, then no other person is going to be able to see your vault contents.

There’s nothing we can fully trust literally. Software have bugs and 0day vulnerabilities.

As I said, web browsers have huge complexity. They have tons of APIs for communication, sharing and modification for web sites and extensions. They download and execute arbitrary scripts from web sites. I know that scripts are executed in sandbox, but still software have bugs and vulnerabilities. I don’t mean that we need to drop everything that is not fully trusted, all I prefer is to reduce such things in security scenario.

1Password works by creating a WebSocket server on localhost, and then the browser extension connects to ws://127.0.0.1:6263/4 and requests passwords without any authentication other than the Origin header.

Wrong implementaion doesn’t mean that architecture is wrong. I expect that I can confirm, approve and select a login item on desktop client, as I said in description above. Similar problem exists for Bitwarden’s “approve unlock requests from other clients” feature and Bitwarden avoids it by explicit finger-print.

Edit: And this 1Password issue is just an example of “software have bugs and vulnerabilities”.

@witdarben I’m not sure what to tell you. If you don’t trust browsers, then you should not be using the Bitwarden Desktop app either, because this app is just a Chromium browser (as it is implemented on the Electron platform). You can use the mobile apps or the command-line interface, unless you have some reason to distrust those, too.

Good luck with your feature request!

If you don’t trust browsers, you should not be using the Bitwarden Desktop app either, because this app is just a Chromium browser (as it is implemented on the Electron platform).

You took me wrong.

As long as the app doesn’t download and execute arbitrary codes from the internet, then it’s ok. Btw, I can also have configuration to disallow it from visiting arbitrary internet servers except the vault server. Its environment is more controllable and closed. OTOH browsers are used to access the open internet by definition. Its environment is open and less controllable. Of course, you might say, I can just not to use the browser extension at all. Yes, as I said above, this feature would be trade off between convenience and security. And of course you’re free to reject the feature request with just “no plan”.

I trust software that I use, not fully of course. But I still prefer reducing disaster range when disaster comes, e.g., when software have vulnerabilities exposed, starting from the most important and most likely places.

The fact that software might have vulnerabilities doesn’t mean that I don’t trust them at all. OTOH that I trust a software also doesn’t mean that I have to YOLO on it. The world is not binary. There’s balance.

Pushing an example extremely, if you always fully assume that users always fully trust all softwares they use and all websites they visit, then password managers should not exist. Users could just save their passwords in plain text file on their devices.

Also for the 1Password issue you mentioned, do you think 1Password users should not trust it? Did you tell Bitwarden users “please don’t trust us anymore because we just fixed a CVE”? What if there’s a vulnerability from a dark corner of Bitwarden extension and the extension have ALL decrypted password? Please allow me to re-state again, I don’t mean there’s one already and I don’t mean that I don’t trust the extension at all. I just prefer reducing disaster range when disaster comes. Nobody can say that Bitwarden extension will never have vulnerability. Once again, you might say, same thing applies to every software. Yes, that’s exactly why I always prefer reducing such things, rather than fully trusting and YOLO every software.

Anyway, thank you. I take your suggestion to stop using Bitwarden. Good luck with Bitwarden users.