How is the connection between Strongbox and the Browser extension secured?

[robojones]

I prefer using the browser extension over copying them to the clipboard because any app on my computer can read the clipboard. I was wondering how the connection between the browser extension for third-party browsers (Chrome, Firefox) and the Strongbox app is secured. Is there a mechanism in place to prevent other applications on my PC from connecting to the Strongbox app and reading my passwords?

If not: Wouldn't it make sense to have some sort of authentication mechanism between the browser extension and the desktop app? Like copying some kind of code from one to the other or something similar. I don't like the idea that just any application on my computer can connect to my password manager.

[strongbox-mark]

Hi, Yes, sure. We use Native Messaging for communications between the browser and Strongbox. This uses stdin/stdout as the channel. So, local on device IPC (inter process communication). You can read more about that here:

https://developer.chrome.com/docs/apps/nativeMessaging/

For technical reasons (browsers launch a new process for each message) this goes through a small proxy helper app called "afproxy". Afproxy then communicates with Strongbox using a Unix Local Domain socket for IPC. So, again local/on-device interprocess communication. So no TCP/IP or networking sockets or open ports or anything like that. You can read more about these here:

https://man7.org/linux/man-pages/man7/unix.7.html

To avoid casual snooping we also encrypt all traffic end to end using asymmetric encryption (e.g. public/private key pair) with a technique called a "Crypto Box" or a "Secret Key Box". You can read a bit more on that here:

https://libsodium.gitbook.io/doc/public-key_cryptography/authenticated_encryption

You can find the code for all of this here on Github, just look under the autofill-proxy subfolder.

Having said all of that, our baseline assumption is that we are working on a secure device, and we consider all bets to be off if there's malicious code running on your device. It is extremely difficult if not impossible to protect against any kind of threat in that situation. If your machine is already compromised, or an attacker is capable of running arbitrary code locally, then there are easier ways to get your secrets than hacking the IPC mechanism of an already unlocked database, e.g. keyboard monitoring, screen recording, in-memory debugging/dumping etc. To address your second question, it's possible for a dedicated attacker to develop a program that pretends to be say Chrome and request passwords using this mechanism. This would be a special form of malware but you'd have to have it on your system and you'd have to allow it to run, and the database would have to be already unlocked. This is an unlikely scenario, but of course it's possible, just as a special case of the more general point above about running malicious code on a compromised system. This is in a different league of sophistication than a random app reading your clipboard, so hopefully that will ease some concerns you might have.

However, we're definitely open to suggestions here on any improvements you can think of or suggest, with the proviso/caveat that we wouldn't want to add any major friction (including codes/registration in the normal/happy path) to the setup for most of our users. We want to remain super user friendly here, so we don't require our users to jump through any extra hoops to get up and running with our AutoFill browser extension.

If you have any concerns around any of this personally, you can switch this functionality off completely:

Preferences > Advanced > Enable Third Party AutoFill > Switch OFF

Hope that helps and open to feedback here :)

[robojones]

Hey Mark, thank you for the extensive answer.

Having said all of that, our baseline assumption is that we are working on a secure device, and we consider all bets to be off if there's malicious code running on your device. It is extremely difficult if not impossible to protect against any kind of threat in that situation.

It's true that it is nearly impossible to protect against threats, when they are already on your computer. However, as a programmer, I often have to compile and run Node.js applications with tens of thousands of open-source dependencies on my computer. If only one of the developers does not properly protect their credentials (which already happened in the past), malicious code could be executed on my machine. Then, the only thing protecting me are the security features of macOS.

If your machine is already compromised, or an attacker is capable of running arbitrary code locally, then there are easier ways to get your secrets than hacking the IPC mechanism of an already unlocked database, e.g. keyboard monitoring, screen recording, in-memory debugging/dumping etc.

At least in theory, the macOS permission system should protect against that. I would definitely get suspicious if my Angular development server suddenly requests permissions to control the Strongbox process or wants to record my screen and keystrokes. The clipboard is one of the things that remain unprotected, so I don't like using it for secrets.

We want to remain super user friendly here, so we don't require our users to jump through any extra hoops to get up and running with our AutoFill browser extension.

That's probably a good call.

This is in a different league of sophistication than a random app reading your clipboard, so hopefully that will ease some concerns you might have.

I do see the point that it's unlikely that an attacker would specifically target Strongbox and its IPC connection. And using the extension at least protects against programs reading the clipboard.

I should probably just think of a better way (like using virtual machines) to secure my computer from possibly malicious code.

[tchatow]

I notice keepassrpc (https://github.com/kee-org/keepassrpc) requires copying a one time code from keepass to the browser extension to approve it and setup a secure channel.

Yes, there are various ways to steal passwords from Strongbox if you allow malicious code to run - but most of these are locked down by the OS (screen capture, accessing process memory). By contrast sockets don't require any permissions as I understand.

It seems Strongbox should implement something similar to require user action to approve each new IPC client.

[strongbox-mark]

Hi @tchatow, thanks for the comment. It is worth noting that because we use a Unix Local Domain socket and not a TCP/IP socket (as KeePassRPC seems to do), you need particular file access permissions before you can open the AF_UNIX domain socket to Strongbox. So, you'll need to get past the MAC (Mandatory Access Control) system of macOS to do this. Perhaps that's more reassuring.

We're also definitely not against adding a feature like this in the future, though we probably wouldn't want our users to have to do anything extra for AutoFill to "just work" by default. This is a security/convenience trade off and we tend towards the convenience side here.

For power users/advanced users, who do feel that a local code execution/malware attack specifically directed at Strongbox is a possible attack vector from them, or have it in their threat model it would be a good option/extra layer to have.

For the moment, as mentioned above, if this is a concern you have in your threat model you should disable Chrome/Firefox AutoFill in Strongbox, or turn off AutoFill just for a particular database you're concerned about.