Every now and then we receive an email complaining about the fact that passbolt requires an extension to run. Recently we saw an article arguing that having an extension is actually worse from a security and privacy perspective.
It is very important to teach users to exercise caution when installing a new extension. Unfortunately there are still a lot of dubious extensions running in the wild. We are not going to argue about that.
What we want to highlight here is that we believe that in the case of a password manager, an extension is actually a requirement to improve security. While it’s pretty damn near impossible to make people change their mind with facts on the internet, it’s still worth it to clarify our approach to risk management.
What do we mean by code integrity?
In the case of a password manager the security model is different. We believe it is desirable that if an attacker has access to the server, or is able to perform a man in middle attack, they should not be able to insert logic that would allow them to decrypt and exfiltrate the data. It is not possible to mitigate that risk when the application logic and the data are coming from the same server. This topic is not new. While there are some attempts to solve this problem, to our knowledge, no practical open standard has emerged yet.
The solution we opted-for since the beginning of passbolt was to split the application in two parts. One that would be served by the server (the encrypted data), and one that would be served by another channel (the logic to decrypt/encrypt and display the plaintext data). This is done using the browser extension marketplace, e.g. the Firefox AMO and Chrome Webstore. Each of them requires the extension to be cryptographically signed by Passbolt developers with a secret key, to make sure nobody can change that code while it is being transmitted from the marketplace.
Other security benefits
There are some other additional security benefits to using a webextension. One of the biggest one is the ability to roll out updates automatically to all users. As we have seen, not all users care to update their passbolt server as soon as a release is available, even when it contains security fixes. We get it, we’re all busy, and it’s complicated to keep track. The auto-update ability of the extension can provide an additional safety net.
Another more complex security benefit is the ability for the extension to run in a separate DOM and create iframes which cannot be accessed by the page it is running on. In a nutshell it allows passbolt to modify and run on pages without leaking sensitive data (such as a decrypted password) to such pages. There are other security benefits which are described with more details in the security whitepaper.
But why does the extension need so many permissions?
All the permissions that are requested by the extension are useful both from a functional and security perspective. We only request the permissions that we actually use. Here is a quick summary of the permissions passbolt uses and why they are needed.
In order for passbolt to work the web extension needs to inject scripts into the tabs / pages served by the passbolt server. The host permission is needed because since passbolt can be self-hosted, the url of the passbolt server cannot be predicted, and therefore the web client can run on any domain and that’s why the wildcard match pattern is required.
The active tab permission is needed to temporarily access the currently active tab when the user clicks on browser action, in order to enable filling up login forms with passwords or prefill the password creation form.
The Tabs permission is needed to insert the scripts needed to run the passbolt main interface on the domain selected by the user during the setup. The Tabs permissions is required so that the web application can continue to work even when the user switches tabs. By Instance, when a user starts a bulk share operation and navigates to another tab, then the operation will not be interrupted and the operation will continue.
The Download permission is needed in order to download the user private or public keys. While creating an account on their passbolt instance, users can generate an OpenPGP key pair that is stored in the plugin local storage. This key is never transferred to the server, and users need to download it to make a backup copy on their desktop.
The clipboard write permission is needed to allow users to copy a secret or username to the clipboard.
The Idle permission is used to detect when the user is inactive in order to flush the OpenPGP secret key passphrase from the memory when the user is idle after a certain period of time (15min by default).
The background permission is needed in order to implement the long-running logic of the webextension. For example it helps channel all the requests to the passbolt web server in order to maintain a consistent user session across multiple tabs and the browser action popup. Moreover all the cryptographic functionalities are also running in the background page.
Chrome local storage is used to store the user configuration, such as the private and public key, the trusted domain and other configuration items specific to the user. The storage is also used to store the user keyring (e.g the list of trusted OpenPGP public keys). The storage is also used to store passwords and other basic items at runtime when the user is logged in, to speed up operations, and therefore reduce network and memory usage, by storing locally information such as passwords or their associated folders.
Unlimited storage permissions is required in order to store a large number of OpenPGP keys in a keyring, and enable storing user keys which contain image attachment or a large number of signatures. It is also useful for users that have a large number of passwords.
How can I trust you are not misusing these permissions?
Passbolt is open source, you can pretty much check for yourself all the calls to the browser extension API, or HTTP requests that are going out.
Of course not all users are capable of performing such review. For both Firefox and Chrome, our extension undergoes regular reviews by the staff of Mozilla and Google. We diligently implement any advice and best practices they recommend. We also had multiple security researchers screen for issues, on pro-bono basis or as part of our bug bounty program on YesWeHack, or when hired by one of our larger customers.
Doing something fishy for a short term gain would permanently damage our reputation with our users, customers, the marketplace reviewers and the security community. We have absolutely zero incentive to go down that path.
Let’s not forget that in a world driven by greedy trolls, most of us still do have a professional conscience and integrity. We’re just not as loud.
What about other passwords managers?
Yes we know, some other password managers are not taking that many precautions. Some might prefer to favor reducing security in order to on-board users more easily and therefore increase revenues. To be fair, some might implement some other security mechanism that passbolt does not have, to mitigate other risks that they judge are more important.
Ultimately this is up to you to decide what kind and how much risk you are willing to accept. We hope that this article will help you make a more informed decision.
4 min. read
Improving passbolt security with distroless containers
It is undeniable that containers have had a big impact on today’s software engineering. From infrastructure to deployments and development…
8 min. read
Introducing the new “Folders” feature
Starting with v2.13, Passbolt Pro Edition and Cloud now includes support for nested folders, to organize passwords and manage access rights in a simple yet flexible fashion.