It’s hard to believe that 12 years have passed since the first version of passbolt was created. Interestingly, it wasn’t even named passbolt at its initial private release. To celebrate this anniversary, we find ourselves in the perfect position to guide you through a retrospective journey, exploring the events that propelled passbolt to where it is today. Welcome to the “Once upon a time…” of the passbolt lore series, part 1, where it all began.
A Surprising Catalyst: Rapidly Growing Agency In India
Passbolt’s voyage started in India, at E-nova, a digital agency led by Kevin (Passbolt CEO) and Remy (Passbolt CTO) for its initial years. You might be wondering how two guys from France found themselves steering an agency in India, but that’s a whole other storyline for a different blog series.
Back in 2005, E-nova, also known as “The Indo-French Web Agency”, emerged with a pretty unique position for its time: High-quality web development coupled with project management conducted in French set us apart. Back then, outsourcing to India was a prevalent trend and the distinctive approach of the agency led to rapid growth over just a few years. In no time, our modest duo had become a bustling crew of over 50 team members.
Our team evolved rapidly, projects multiplied, and staff was constantly changing. Yet through it all, one problem kept coming up again and again. Yup, you guessed it – password management. With every new project, clients would send the project managers – dozens, sometimes hundreds – of passwords, credentials and secrets via email or skype, which in turn had the agency distributing them among various teams working on the project: system admins, developers, marketing, managers, etc. This distribution was often done ad-hoc, using emails, spreadsheets or skype.
But, this way of working led to a few critical problems:
- Security: We were playing with fire. The haphazard sharing of passwords was a disaster waiting to happen. Sharing all these passwords with the entire team? Saying “Not ideal for security” would be an understatement (ever heard of the principle of least privilege?).
- Productivity: There was a complete lack of centralisation. We struggled with tracking credential changes. We were so busy navigating through mishaps and trying to find passwords that we missed deadlines as the team often lacked the credentials needed to complete their work.
- Onboarding: Onboarding and offboarding of new teammates was a complete nightmare: new recruits had to chase the credentials they would need to do their job, and it was impossible to know what credentials had to be rotated when someone was leaving the company since we didn’t know what they had access to.
What did we do to tackle these problems? We started using KeePass, a nifty password management software. For several years, it was E-nova’s trusty sidekick for password security.
KeePass And The Conundrum Of Collaboration
There are so many reasons why we all adore KeePass. It’s easy to install, user-friendly, versatile, open source, subjected to audits, and even holds ANSSI’s seal of approval, instilling trust. But, we have to face the facts – When it comes to collaborating and using it with a team, it can quickly spiral into a nightmare (something even today we still hear about from our users and clients).
The team at E-nova wasn’t exempt from these struggles posed by KeePass. We used a KeePass file containing well over a thousand entries, genuinely trying our hardest to use it in a collaborative way by...
- attempting to host the KeePass file on a shared server accessible to everyone. Alas, this resulted in multiple unusable archives and lost credentials due to concurrent write operations.
- experimenting with splitting the master KeePass file into several smaller fragments. Predictably, this introduced absolute chaos when it came to organisation. There were endlessly recurring quests for a specific credential or master password that matched a given file.
Ultimately, despite how much we loved KeePass, we couldn’t mould it to align with our collaborative needs and decided to explore alternative password management methods.
The Search For A KeePass Substitute
Fast-forward to 2011, Kevin’s patience is worn thin with the bottlenecks with password management. Determined, he sets out to find a replacement for KeePass. At that time, there were a few password management solutions out there, such as 1Password and LastPass. But, these were consumer-oriented solutions and far removed from the needs we were experiencing at E-nova, as a technical team consisting of developers, system admins, testers, project managers, etc.
We’d grown fond of KeePass and wanted an alternative that had a lot of the same attributes:
- Installable on-premises, shielded behind the company firewall.
- Open source, auditable, with the ability to build on top of it.
- Third-party audited.
- Flexible and powerful password organisation based on folder hierarchy.
But, there were other features missing that we looked for, including:
- Traceability: The ability for managers to trace users' access and monitor activity on credentials.
- Powerful & granular sharing: Should allow users to share a single password with a single user, or an entire folder with subfolders with a group of users. Inheritance should be supported and should handle complex project structures.
- Portability: Option to integrate with the browser for one-click login.
- Automation: API-centric architecture that accommodated potential automation scenarios at a later stage.
Given this exhaustive list of requirements, as you might guess, finding a solution that came remotely close was impossible. A majority of existing solutions catered to individual users and lacked on-premises hosting or sharing capabilities. In a burst of optimism, we decided to leverage our expertise and do what we do best: develop our own solution.
Caution: this is usually a bad idea, don’t try this at home.
The First Iteration Of Passbolt
The initial version of passbolt took around half a year of development and made us quite happy. The name “passbolt” emerged during a brainstorming session, chosen for its simplicity. Anecdotally, an alternative name that we considered was “passwala,” meaning “the password guy” in Hindi. It’s worth mentioning that at this point, the software wasn’t intended as a standalone project; it was solely for internal use within the agency.
Leveraging CakePHP and jQuery, the initial prototype of passbolt took shape. It probably won’t look familiar at all because it’s undergone substantial facelifts. While the design has changed significantly, we kept the fundamental functionalities the same. From this first version, passbolt has always focused on security, privacy, and easy collaboration (effortless sharing of passwords).
Following the debut of the first MVP for internal agency use, it became clear that passbolt was providing significant value in terms of productivity and security. All the password management problems from before were immediately eliminated. Beyond that, a growing number of agency partners and clientele began expressing interest in passbolt (they were granted access to share project credentials) and requested we share the source code. We discovered they were also facing similar challenges with password management and couldn’t find a suitable platform. Consequently, we started sharing the source code with some of them.
From side project to product
After spending substantial efforts, way more than anticipated, in developing the first iteration and beginning to use the solution, as well as getting early positive feedback from the first adopters, it became clear that passbolt had much more potential than just being a side project. This made us decide to package passbolt as a product and create an explanatory video so that we could at least explain easily what we had built to other people.
Lessons We Learned
It’s never just a side project
When we started developing passbolt at the web agency, we thought it would take a few weeks at the most. Well, it turned out that the first iteration took 6 months, a lot of focus, and Kevin became so obsessed with it that he eventually decided to leave the agency to focus solely on it. Building good software takes time and focus. It's rarely something you can do “on the side."
Feeling the pain point is a great reason to start a project
The fact that we felt the pain of password management as a technical team first-hand is likely the main reason why we found user adoption of passbolt relatively fast. Passbolt was built as a result of our own team's frustrations, and as we later realised, there were many other tech teams out there facing the same challenges. This helped us build a product that aligned with their work ethic and values, as we were one of them, and gave us the initial traction we needed to take it to the next level.
Moral of the story? If you’re trying to invent a solution when you can’t find one, chances are you’re not alone. Innovation often sprouts from the soil of necessity.
