apidays LIVE Paris 2021 - How password managers are built for Privacy and Security by Frederic Rivain, Dashlane

Editor's Notes

1. Welcome! I hope you can hear me ok?
2. My name is Frédéric RIVAIN. I am the CTO of Dashlane. Who knows about Dashlane ? We build a Password Manager, to help you manage your digital identity in a safe and user-friendly way. Today, I’d like to talk to you about how we think about Privacy and Security at Dashlane.
3. We were founded 12 years ago and we have a distributed team between France, Portugal and the US. Our product serves both consumers, B2C, and the enterprise world, B2B. To give you a sense of scale, we have around 20 “Product & Engineering” agile teams.
4. When we think about Privacy and Security, it is really the 2 sides of the same coin for us. You can’t have one without the other. Because we store very sensitive data for our customers, their logins and passwords, their payment information…it is mandatory to ensure that data is secure and private, only accessible by the users themselves. Our product, password managers in general, must be built by design for privacy and security.
5. Let’s start by the perspective of privacy.
6. Firstly, you need to be clear about what data you have and how you classify. For Dashlane, we have 3 main categories: The customer vault: that’s the core of our product. Everything the user stores in there. Obviously critically sensitive. User Data: we have 2 flavours of those. Acount data, things like the email that was used to create an account. We don’t need much on that front, and we try to minimize what we have especially PII. The second flavour is event data, logs, that we collect about usage of the product. Yet again we try to be frugal about it, but we do need some of it to operate, improve the product, do marketing. Finally, what we call activity logs, which are logs related to how our users use Dashlane to interact with web sites and online services. Of course, we don’t want to know what a specific user is doing. We consider those logs as sensitive data, so they are anonymized and aggregated. Let’s do a deep dive in each type of data.
7. The way we manage the customer vault relies on a security concept called Zero-Knowlegde Architecture. It implies that nobody can access the user data, except the user themselves. Everything is built around that very simple notion, but which is pretty complex to put in practice. The short version of it is that the vault is always encrypted locally on the user’s device, by using a key derived from a secret, the Master Password, that only the user knows. That Master Password is never transmitted or stored by Dashlane. Which by the way means that if you forget your master password, you can’t do a « forgot password ». We can’t give you back access. You will have to start over.
8. The 2 other types of data are generated from the client and stored in segregated databases. User data is directly tied to the user. While Activity logs have been anonymized locally on the client, before being sent to the Dashlane Servers. We are also dropping part of the timestamps to avoid risks of correlation. More filtering is done server-side to ensure there was no issue, and a client did not send unwanted details by mistake. Because of the diversity of those logs and data, we run a Data Privacy Committee, a group made of CTO, CISO, General Counsel, Data, Product to have an ongoing review of our practices and in particular evaluate and approve the addition of new data point or logs. One thing to keep in mind as regards that type of data is that with the explosion of SaaS tools we use, some of that data is duplicated to third-party services, which increases the risk and the contamination. Think about platforms like Salesforce, Braze and Sendgrid, Zendesk, etc.
9. A word about the compliance side of privacy. Our world is becoming more regulated, so this is not something you can avoid. You should always try to minimize your compliance exposure. The more you can limit the need for PII or for regulated data type, the better you are. Obviously not always easy depending on your business. To facilitate compliance work and audits, ensure you have strong segregation between your different categories of data, that you maintain an up-to-date inventory of all data items, where they come from, what is their sensitivity, how are they used, where they could be forwarded. Of course, you need to define your retention policy per data type. How long should you keep each data type. There are mandatory flows in regulations like GDPR or CCPA (which is the Californian version of GDPR), so ideally you automate all those flows so that you respect the rules. For instance, deletion of account, which you should automate across the board, including deleting data from third-parties. As a side note, Apple recently made it mandatory in iOS apps to offer in-app an access to delete your account. All your practices should be compiled into your Privacy Policy that you publish on your web site or in your applications. One thing I like about the Dashlane one is that there is a summary in plain English, before the legal jargon.
10. One last thought about privacy: it must be an on-going conversation inside your organization. We are not in a static world, so it is important to always review our practices, how we can find the best solution for the business while ensuring the privacy of users. For that purpose, we have built our Privacy Stance a little like the three laws of Robotics from Asimov. It is a set of principles, from the highest order to the more specific. Principles must be considered in order, and principle 2 cannot go against principle 1. Number 1 : Dashlane (as a company) should never be able to access end-user data (here we are referring to customer vault) Number 2: that’s related to the B2B context. As an employee, you have a work space and a personal space in your vault. The Admin can know certain things that happen in the work space, but not in the personal one. Number 3 refers to logs and account data I mentioned previously. Finally, when we want to customize and personalize the user experience, most of the time it needs to happen client-side if we want to maintain privacy. If you do not have a privacy stance for your organization, I encourage you to create one.
11. Now, let’s look at the other side of the coin.
12. Security is about keeping all of us safe: obviously our customers, this is one of the key purposes of our product. But also our employees and our Company, that is to say our shareholders. Considering our business, it is essential for us to exist. It involves building a secure product, but Security is also a core feature, that we can use as a marketing unique selling point. There are 2 additional important considerations for Dashlane’s mission: we consider we have a role to play to educate our users. Most of them will start using Dashlane because of the pain point of managing their passwords, not because they care so much about their security. Yet if we onboard and educate them the right way, we will raise their awareness on security and improve their safety. Last but not least, we hope at our level to influence the digital world, make sure privacy and security become more and more foundational on the Internet. An example if our participation to the FIDO alliance and how we contribute to pushing for multi-factor authentication solutions.
13. Let’s start by a given. Security is Mission Impossible. Dashlane will be breached one day, or will suffer a critical security incident. So let’s be pragmatic about it: the goal of our effort here is not to guarantee that nothing bad will ever happen. The goal is: To minimize the likelihood of it. It is a game of cat and mouse. We aim at making it very complex and expensive for an attacker to target us. That way they focus on other easier targets. Making sure we are able to react to a security crisis can make a huge difference, depending on how prepared you are. Are you able to react very fast? Make sure you have the counter-measures in place, the right internal crisis organization, the investigation capabilities…You should design your own Code Red Plan and rehearse it. Finally, we strive to minimize the impact. If something bad were to happen, how can we make sure we limit as much as we can the impact for our customers and for dashlane? All in all, so far so good. We never had a public security crisis or a breach, as far as we are aware. But that does not mean we should stop investing and consider it will never happen.
14. So, if someone wanted to hack Dashlane, how would they do it? Let’s identify the attack vectors, the main threats. What would be the impact ? What is our exposure? What mitigations can we put in place to limit the risk? What should our response be to those attack vectors? This is our Threat Model.
15. There are 5 main attack vectors against Dashlane. We are going to deep dive in each one of them, but here is the high-level view: Compromising the Dashlane application: mostly bugs and vulnerabilities of our software. Hacking the user’s device: planting a malware or a keylogger for instance. Attacking our servers Breaching our internal IT Exploiting the human factor, the insider job, whether it is by bribing or threatening an employee, or because one of them goes rogue.
16. Let’s look at the first attack vector.  No code is perfect, there are always bugs and issues, that some malicious actor could exploit to get access to customer’s data. It could be a bug in a client application, or a man-in-the middle attack to intercept communication and capture data in transit. The impact here could be around leaking some user’s data, depending on where the vulnerability is. A common theme to most attack vectors is the reputation risk. Even if the actual impact can be limited, the impact on Dashlane reputation and the communication in a security crisis are always very critical to us. There are many ways to mitigate that risk. Most of them related to best practices of secure software development: code analysis, code review, multiple layers of security reviews, removing old code continuously. I want to highlight 2 of them: The concept of a zero-knowledge architecture. It is a very simple principle. Our goal is that only the user can access their own data. Nobody else. Not Dashlane, not a hacker, not a governmental agency. Our whole product is built around that security concept. It makes developing Dashlane way more complicated, because a lot of security logic needs to happen on the client and involves complex cryptographic processes. But this is at the heart of our security. Bug Bounty programs: even if we have a team of dozens of security engineers, it would not be enough. The more eyeballs you put on your code, the greater the chance someone finds bugs. So we use bug bounty programs like HackerOne, where we ask white hat hackers to investigate our code and try to find vulnerabilities. Our Head of Security likes to call those platforms the Uber of security.
17. The second attack vector is the compromission of the user’s device. What if the user’s laptop is infected by a malware, a trojan, a keylogger. The attacker could then steal the user’s data directly from the device memory. Device compromission is kind of game over, since the attacker is inside the house already and has the keys to the house. Unfortunately, as Dashlane, there is not much we can do to prevent this. This is really more of an OS level challenge to mitigate against those malicious attacks. Still we try to make the life of the attacker more complicated by using techniques such as obfuscation in memory, hardware encryption using secure CPU enclave, or advanced 2-factor authentication.
18. An attacker could try to penetrate our servers on AWS and steal the encrypted user data files from our servers. In practice, I don’t think that would be the most effective attack. Doing so, the attacker would get access to millions of small encrypted files, without having any of the keys, thanks to our zero-knowledge approach. They could of course try to brute-force each of those files, but that requires massive amount of computing power and time. Server-side security hardening is a well-known activity, no need to reinvent the wheel: here we leverage best practices from the industry and from standards such as PCI-DSS or SOC2, we benefit from the built-in security of AWS, as well as from years of the tech community to server security. For Dashlane, it is about enforcing our zero-knowledge concept and making sure we follow those best practices tightly.
19. Compromising our internal IT infrastructure is more of a big deal. The use case here is not about stealing company confidential information. It would be for the attacker to get access to our development environment, so that the attacker could plant malicious code or  backdoor directly inside the Dashlane product, which would lead us to shipping a compromised version of Dashlane to all users. As a startup, this one is the trickiest, since you need to find the right balance between strict IT security and employee productivity. Of course, we lean more on the security side: 2FA everywhere, strong network security with breach detection mechanism (we use a tool called Darktrace), Tight IT processes such as « least privilege access » (you should have access to the minimum, only the systems that are required for you to do your job)
20. That last attack vector has a similar impact as the IT breach. One comes from the outside, the other one from the inside, but the risk is similar. We trust our employees, but for their own safety, we also need to ensure that if one or several employees were bribed with money, threatened, of one of them went rogue, they could not harm our customers and our company. The sensitive system is our software factory. We make sure to have a very secure release pipeline, with full traceability. You need approval from multiple engineers to be able to ship code. We sign the Dashlane client application. The goal here is to make sure one employee could not ship a corrupted Dashlane build. 
21. I want to leave you with 3 key take-aways: Privacy and Security is not a topic, just for the security and legal teams. It needs to be a company conversation. It needs to be something everybody is accountable for. It will not happen by magic. There needs to be work and effort put into Privacy and Security. You should be proactive about it. Most of the time, it is about common sense. You don’t need to reinvent the wheel. Just do what seems the most obvious in your context. Keep it simple but integrate it from the start.
22. Be safe, be the ambassadors of privacy and security in your organization. And use a password manager! Thank you.