 I've got two main questions and that's if you have a seat in the middle next to you. Take it and get out of people from the side and the other one is please exit fire that way and run fire that way and we can all stream through because it's really popular apparently. Thank you. Would someone have lost some gloves? If so, they are on the desk. What does it work? No. It works for the previous one. I don't think so. There is no focus. It's funny. The previous one works. You are a more French speaker. No, English. I can switch with that. I'm French. That's fine. So, we'll speak now about the password manager. This is Rémo Berthot and he will introduce you with PassVault. Let's applaud him. Thank you. I would like to start by saying thank you to the volunteers and the organizer for us them. They are doing a good job every year. So, if we can give them a little applause there. So, today I'm going to talk about an open source password manager that we developed. So, it's 2017. We have self-driving cars and jetpacks. And what is the most used password in the world still? Like, can someone know? Hazerti 1234567, that type of password, yes. 80% of security incidents are due to weak passwords that are reused in multiple systems and that people share on post-it notes. So, it's very likely that if your organization is not using a password manager, you're wasting a lot of time resetting the password for your users instead of doing more important things than, for example, like voting pictures of cats on the Internet. So, this is why we started developing PassVault because we could not find a password manager that was web-based and easy to use and that was designed for collaboration. So, we estimated in 2012 that it would take us four months to develop that software and because we are very experienced web developers, we were right. It took us four months and four years. So, PassVault is a free open source because it's designed for collaboration. For collaboration, we choose to use an asymmetric encryption model and we wanted to work on standards. So, we choose open PGP as a standard for storing and exchanging secrets. So, PassVault is based on web technology. So, the best way to make it extensible is to design an API. So, we choose to have a JSON API to do that. And we like to think it's fairly easy to use. So, I don't know how many of you have tried PassVault. Yeah, I know that you've tried PassVault because you're part of the development team. So, this is the login screen. As you can see, we are asking the master password of the user, which is the private key password. But actually, we are not sending this secret to the server. We use a challenge-based authentication system, which I will describe a little bit more in details. You can see also on the screen that we verified the server identity and that's also part of the authentication mechanism. So, this is the password workspace where you can see the list of passwords. You can create a new password. You can copy it to the clipboard, share it with your friends. Pretty straightforward. Then we have the edit dialog. So, you can see on that screen that we have this orange-looking field, which is actually a mechanism that helps prevent phishing. So, this is to make sure that this field is actually managed by the plugin and inserted on the page in an iFrame and controlled by the plugin. So, that way, no other JavaScript running on the page can actually access this data. And the color and the tree letters are actually selected by the user during the setup and can be changed. This is a mechanism that we have not invented. That's what other plugins are doing. For example, if you know Mailvelop that enables open PGP-based email encryption, they use a fairly different system, but the principle is the same. So, this is what you get when you share a password with someone. So, you can select the right if someone can read or update that sort of thing. This is the user workspace where you can see the list of users that are actually on the system. And we will add more functionalities because we'll be soon supporting groups. So, this is pre-empty, but it will become a little bit more busy. So, this is the edit profile screen where you can change your picture and manage your keys. Obviously, we'll have more settings coming up here in the screen right now. It's fairly simple. So, this is the command line interface. It's a proof of concept that we develop in Node.js and we receive very positive feedback from the community as you can see in the testimonials. So, yeah, people were not too happy about us doing it in Node.js, so we might as well redo it in technology in the future. But I was more proof of concept to show that you can extend passwords. So, that's another feedback that we got. Can you please develop faster? Yes, Laura will think about it, especially if you help us and contribute. So, what is in progress right now? As I mentioned, we are working on groups. We are working on API documentation and doing a risk analysis, but we have actually done a risk analysis, but it's more like making it more available for everyone and making it tidy so that you know what is the threat model, what are the compromises that we made and the countermeasure that we've put in place for some other elements. And then in the next quarter, we'll work on importing export, audit logs and email notification. So, I don't know why there is a disclaimer at the bottom here because we are pretty good at estimating timelines. So, we have the group screen. So, right now the specs are available. So, we have wireframes. All the user acceptance scenarios are also described there. So, if you want to check out on our website and give us some comments, we started building last week, but you know, you can still comment. And after that, we're going to work on security audit categories and tags and mobile support and all sorts of other features that have been requested by the community. So, I would like to spend the next seven minutes or so, hopefully, about how does Passbolt work. So, getting a little bit in the details of how we've built Passbolt. So, we use an open source stack, which is based on KKPHP in the back end, which is compatible with MariaDB and MySQL. Next week, we're going to make a release that hopefully make it compatible with PostgreSQL. We use on the front end, CanJS, which was called JavaScript MVC in the past. And now we use in the front end also OpenPGPJS, which is an open source implementation of OpenPGP, which is used by other clients like ProtonMail, I don't know if you've heard of them, or MailVelop. On the back end, we also use GNU-PG, obviously, and we use the GPGB mining bindings for PHP. And yeah, we also use Docker and all sorts of other goodies, which you can check on our website. So, this is the database model. I didn't put the details for the tables because there's not much space. And what is interesting to see is that we are actually storing the GPG keys in the database, which have security implications. We don't use a key server for that. So, if you're interested about finding, like discussing why we did that, we can talk about a little bit at the end. We also store the secrets each time for each user, so we don't store like a multi-part GPG secret. So, one PGP message doesn't include all the passwords for all the users. We store one GPG message for each user. And every time someone edits the secret, we also keep the previous version. And we have all sorts of other information there, like authentication logs and tokens and all that. So, this is the KPHP architecture for lifecycle or for request, more like. So, if you use Django in the past or something like Ruby on Rails, you'll feel at home. I'm not going to describe that because I've been told this is pretty like standard now. So, this is the GPG authentication sequence diagram. So, go, you know. So, we have... It's pretty much if you use SSH and your key to log in into SSH is pretty much the same principle. So, it's a challenge-based authentication where you will have to prove your identity by decrypting a secret and sending it back to the server. So, what is interesting is that because the server also have that key, it has its own key and the client key and vice versa, we can do the authentication both ways. So, we can authenticate the server and we can authenticate the client. These have several advantages compared to a normal password, the password for each authentication round change and you're not limited to the size of the passphrase. So, you can use a very, very long authentication token that is unique every session and that is not linked to the length of the passphrase of the user. So, this is the architecture for the plugin. So, I'm not sure many of you are familiar with developing browser extension, but basically you have two parts. You have the add-on code which have access to the interesting functionalities like high-level APIs like toolbar or clipboard or that sort of privilege APIs and you have the content code. So, the add-on code cannot modify the HTML in a page and the content code cannot access the clipboard or that sort of thing. So, you need to interact between these two sandboxes using a service worker that basically send messages and back and forth in both directions and what is interesting in this model is that even the content strip is in a different sandbox than the JavaScript running on the page. So, for example, if I'm running Passball.js on a particular page where we inject a script from the plugin, the Passball.js cannot access the data or modify the script that is running in the content script sandbox. So, this is interesting in terms of security because it makes things a little bit easier. So, we have quite an extensive test suit to test all the different scenarios. We have around 300 Selenium tests. So, these are tests like as a user I go to the setup and I don't know the private key and then I do stupid things and this should be the result. So, we have 300 of them and we have a PHP unit test to test the API. We have a Chai and Mocha test to test the JavaScript framework that we use and we have two continuous integration stacks. So, if you run these tests in a normal setup that will take around two hours to run them all. So, at the end, we've built a little bit more clever stack where we distribute the load across like 10 nodes so we can run all these tests in 10 minutes so that Cedric doesn't have any excuse for not coding. And we also have a style guide. For example, we have a website. We have a browser extension. We have the Passable.js running on the page. How do we maintain all this look and feel consistent across all these different products is by using an NPM package. In this NPM package, you also have like test screens and we also have wireframes that you can... It's based on Actio, so it's not open source but it's out there if you want to help us make wireframes. So, I would like to thank you for your time and you are welcome to help us contribute to Passbolt. You can, in whatever capacity that you're interested in, you can also just give us a review on the Chrome Web Store or Mozilla browser extension. Thank you very much. Thank you for the call. Would someone have a quick question? Yes, you can... Passbolt is 100% open source.