Big Issue For Our Company to Adopt Passbolt and Feedback

We recently installed passbolt for our company and we are loving it! We like that everything is audited, that the source is available, and that you take security seriously.

However we’ve run into a big issue that might be a deal breaker for us. We are a small company in a service industry with a team of technical people and other teams of non-technical people. We were thinking of storing all kinds of sensitive accounts in passbolt, things that obviously we wouldn’t want just anyone to access. But if we were to use passbolt for everything related to the company, we are worried it might introduce a single point of failure. If for some reason the passbolt server goes down, the whole company might be left without access to all accounts. More so if we add random passwords + password rotation policies. Imagine just a day without access to any accounts, it would be catastrophic for us.

Ok, we can do automated backups, and restore from them. But the process of deploying passbolt and restoring from the backup is too involved and not something a non-technical person can do. Also if a technical person were to do it, it would have to be a very trustworthy person within the company, since if they have access to the server they could with some effort access all accounts.

Currently I’m the one tasked with this, but if for some reason I was absent, there is no other person in the company that the stakeholders can trust to do this process.

This big con might just offset all of the pros of using passbolt. We can’t tell everyone to change their passwords to strong ones and rotate them every so often knowing that if the server goes down we will be locked out of all our accounts.

What we’d like ideally is for there to be a local passbolt application that keeps its database in sync with the entirety of the passbolt database in the server. This application is installed in a set of secure desktop machines. In the case of failure in the server and that we are unable to safely restore manually from the backup, a non-technical person with their respective credentials can login in to the secure machine through a GUI and still access their accounts.

Ideally then the non-technical person has time to contact a trustworthy organization and have them deploy a secure passbolt server and restore from backup, but they are not locked out in the meantime.

I read in the roadmap that you are in the process of implementing a desktop application and two-way sync with keepass, we look forward to these, but we are wondering if this use case is considered. For these solutions to work for us, the local application would have to keep a copy of the entirety of the database, meaning all passbolt users can physically log in from the secure machine with their respective credentials and retrieve their accounts from the local database copy.

By having this application in a secure machine(s) inside the company and easily accessible by non-technical users through a GUI, the risk of the server going down and being locked out of all accounts is completely eliminated. Also there would be no need of manually configuring automatic backups since the desktop apps would do it for themselves.

Maybe you’ve already considered this use case, but still I hope that this feedback is useful to you so you can keep building great products and continuously improving them! Thank you for taking the time to read it through.

Hi and thx for the feedback.

Did you considered going to the cloud instance to delegate the hosting headache?

Desktop app is planned for next year.


Yes we could use the cloud, but still I think it is important for us to keep local on-premises backups that are also accessible to non-technical people just in case.

My company is in a similar situation. We self host. To reduce potential downtime, we’re using the following infrastructure, which is a relatively low-budget solution:

  • Cloudflare load balancer
  • Two VPS web servers in different Vultr datacenters, configured to only accept traffic from the CF Load Balancer
  • Three database servers in different datacenters, managed by Scalegrid, hosted in Digitalocean
  • Automatic database backups that occur every 30 minutes to save to our local infrastructure and archive a copy in AWS S3

We’ve tested it all several times, and the failover happens so quickly that users don’t even notice the downtime. :slight_smile: It would be simpler, but not cheaper, to put all the infrastructure in one environment, ie: AWS/Azure.

If you’re at all interested, I’d be happy to provide consulting services to help implement a similar solution for your company. We’re an outsourced IT firm, so this is what we do professionally every day. Passbolt has been critical to helping us scale and work efficiently and securely.

1 Like

FYI- this is one reason I love Passbolt. :slight_smile: This is technically not true, due to the method/implementation of encryption. Even someone with full root access and the entire database can not decrypt users passwords without having their private key and their passphrase. I like this approach, because even if a “bad guy” somehow gained root access on our infrastructure, they would not be able to get anything useful.

At the end of the day, the important contents of the database (i.e. the login credentials) are just GPG-encrypted text. This was the number one selling point on why we chose passbolt over other solutions - there is absolutely no proprietary encryption/storage format. just plain, simple and battle-tested GPG.

Hence, if passbolt would go out of business tomorrow, your on-premise installation blows up and you completely failed at having proper, working backups of the passbolt VM/jail/zone; essentially the only thing you need are DB-backups/dumps that you have anyways…
Basically you could extract all the GPG-encrypted strings for each user from a DB-dump with a simple awk script and let every user decrypt them with their private key and passwords. The private keys (“recovery kits”) can/should be also backed up - we use encrypted ZFS datasets for backing up such data and replicate the snapshots to our backup servers (one could also use an encrypted dataset for the passbolt jail…).
The person handling the backups and/or keys wouldn’t even need to be 100% trustworthy, as the keys and encrypted data are still worthless without the user passwords. and besides: if you can’t trust your IT staff, you have much bigger problems than your credential store…

Yes, you can create a single point of failure with passbolt if you omit all good practices and are absolutely pendantic and irrational about not backing up any private keys or database for “security reasons”. But this also holds true for every other solution. IMHO keeping a complete copy of a vault on every endpoint is a much higher security risk, especially if proprietary, closed-source encryption is used that might have some (deliberate or accidental) backdoor in it.

If you want an even simpler (in terms of moving parts) and more observable solution than passbolt, have a look at pass ( as this is essentially a pure shell wrapper around gpg & git and stores in simple text files instead of a database. I’m still using that as my personal solution in combination with GPG-keys on a yubikey. The major advantages for me (besides OTP support): it takes absolutely any data you can put in a text file and it fits my workflows a bit better than passbolt (which really is a heavily browser-focused solution).
OTOH - non “technical” people (i.e. the typical windows mouse nugders) will most likely be completely overwhelmed by typing some simple commands. There are GUIs available, but they don’t cover 100% of the use cases, so you occasionally still need to drop to the console for some tasks. (And if you have to support windows boxes you’d have to deal with cygwin, which might also cripple some of the interoperability e.g. with browser plugins)

1 Like