8 min. read
How we migrated Passbolt front-end to React
This article will give you an overview of this React migration journey. Most of the discussed technical details come from the style guide repository.
Passbolt team
11 February, 2021
Passbolt team
22 April, 2021
Security is one of the most challenging aspects of building an open-source privacy-focused software like Passbolt. As the adoption grows, so does the pressure to find and fix any security issues. If you have been following the project for a while now you may already know that we have in the past organized code reviews by partnering with framework specialists, security auditors and bug bounty hunters.
As part of our renewed effort to demonstrate our level of commitment to the community, as well as support our current certification efforts, we will be organizing a series of security audits in the course of 2021.
The first part of the audit focused on the overall architecture and security properties of the solution, including some blueprints of the upcoming evolution required for the mobile application. The next parts will focus on the implementation details of the different components such as the webextension, the mobile app, the server application, the command line interface (CLI), and so on.
For this first part we were excited to collaborate with the team of Cure53, which we had the pleasure of working with as part of previous work done on the Mailvelope project. Their experience and track records with security audits, for example with products such as Openpgp.js, made them the perfect match for this project.
Report conclusions
So, without further suspense, let’s jump straight to results, by quoting the report:
The cryptography of the project was examined by two members of Cure53 over the course of six days, with the results amounting to seven findings of varying severity and seven informational findings.
Despite the relatively large number of findings, all findings were written from a critical perspective of the specification, and therefore do not necessarily have a practical impact on the software implementation for Passbolt.
PBL-01–001 and PBL-01–004, which deal with transport layer encryption as well as nonce generation and management for authentication operations, were marked as high severity because they outline omitted information in the provided specifications that could cause implementation decisions to be made with high potential security impact. PBL-01–002, PBL-01–005, and PBL-01–009 also deal with undefined behavior in the specifications, but which [have] less severe potential consequences on software implementations.
The remainder of the issues, most of which are informational-severity, deal with recommendations towards hardening the specification without touching upon any details that could have a current tangible security impact on the security of the Passbolt cryptographic design. In conclusion, while Passbolt’s existing cryptographic specification design could benefit from clearer and more complete definitions in certain areas (as outlined in this report), the specification itself illustrates a relatively well-designed protocol with no immediate outstanding security issues.
Some comments on the high ranked issues
While we won’t dig in all issues in this blog post, let’s have a look at these two issues marked as High:
PBL-01–001 Crypto: Secure Channel Enforcement Recommendations
In short this issue applies to people using passbolt without TLS enabled (e.g. without https://) or with TLS configuration with insecure settings.
Currently passbolt does not enforce HTTPS by default, however a badge in red will display “Unsecure mode” in the footer , with a link to a page explaining why https is important. Moreover, passbolt currently does not make recommendations, in the installation or the healthcheck, on which protocols or cipher suites should be avoided.
For this issue we believe that this is the responsibility of the server administrator, e.g. the person or company hosting your passbolt server, to make sure that TLS is configured correctly using tools such as SSL Server Test. In the future however, we will consider adding an additional layer of encryption between the client and server, as suggested in the report.
PBL-01–004 Crypto: Nonce Generation Recommendations
This one concerns the implementation of GpgAuth, the challenge-based authentication protocol which passbolt uses. This protocol relies on unique challenges that must be decrypted by each parties (the server and the client) in order to authenticate. While the protocol specifies that this random challenge should be a nonce, the current implementation relies on randomly generated tokens in the form of UUIDs that may not be used exactly once.
Rest assured that at the moment there are no practical exploits to break the authentication protocol, as the chances of generating the same UUID twice are pretty slim. According to wikipedia “the number of random version-4 UUIDs which need to be generated in order to have a 50% probability of at least one collision is 2.71 quintillion”.
However we will be implementing and rolling out the suggested fixes from the report, to both extend the size of the challenge and ensure nonce correctness, in upcoming versions of passbolt GpgAuth implementations.
Other issues and suggestions
Additionally the report contains some other interesting suggestions which we already had planned to implement:
Password expiry flag: when a user is removed from the permission list or a group the resources should be marked as expired. You can find the specification for this feature here.
Passphrase generator: the users during the setup and on the password generation screens should be offered by default with the option to generate a passphrase created using the diceware method. You can find the specification for this feature here.
Some other remarks on existing limitations of passbolt that we consider outside of our “control” (such as OpenPGP standard currently not supporting algorithms for asymmetric keys that are quantum resistant), will be added to the security whitepaper version 3.1 for completeness.
Conclusion
We would like to thank the Cure53 team, and especially Dr.-Ing. Mario Heiderich, Dr. Nadim Kobeissi for their detailed report, as well their advice on how to better present the existing risks of the solution to the community. Additionally we would like to express our gratitude to Thomas Oberndörfer from the Mailvelope team, who helped us prepare the documentation for this audit.
Of course the full report is available for everyone to review here, and our comments on a dedicated incident page. Stay tuned for the second part which will cover a code audit of the webextension.
Feel free to reach out at [email protected] if you have more questions, or in the comments section below.
