How We Think About Security at Dashlane
Security is about keeping all of us safe. First and foremost our customers, obviously. But also our employees and our company (including our shareholders).
There are 2 additional important considerations related to this part of 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.
- We hope to be able to influence the furtherance of digital rights across the globe by making privacy and security more foundational and accessible on the Internet, whether that is participation in the Facebook ad boycott with #StopHateForProfit or pushing for multi-factor-authentication solutions.
Security is hard
Let’s start with a given: Security is hard. And perfect security is impossible.
One day, Dashlane might be breached or suffer a serious security incident.
So we should be be pragmatic about it. The goal of our security effort here is not to guarantee that nothing bad will ever happen. The goal is:
- To minimize the likelihood of a security breach. This is a game of cat and mouse. We make it very complex and expensive for an attacker to target us, so that they focus on other easier targets.
- How fast you react to a security crisis can be day and night in terms of impact. We need to make sure we have countermeasures in place, the right internal crisis organization, the investigation capabilities, etc. We have designed a thorough Code Red Plan that we rehearse regularly.
- 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?
We have 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. It's a little like what motorcycle riders say about wearing protective gear: it's not if you'll crash, but when.
So, if someone wanted to hack Dashlane, how would they do it? Let’s identify the attack vectors, the main threats.
What would the impact be? What is our exposure?
What mitigation can we put in place to limit the risk? What should our response be to those attack vectors?
Those questions help us build our Threat Model.
There are 5 main attack vectors against Dashlane.
- Compromising the Dashlane application: this mostly relates to 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 inside job—whether it is by bribing or threatening an employee or because one of them goes rogue.
Compromising the Dashlane applications
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.
Best practices of secure software development are also critical: code analysis, code review, multiple layers of security reviews, removing old code continuously.
I want to highlight two important factors:
- 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 (a customer's computer or phone, not a remote server) and involves complex cryptographic processes. But this is at the heart of our security.
- Bug Bounty programs: even if we were to have a team of dozens of security engineers, it would not be enough. The more eyeballs we put on our 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 for hackers."
Hacking the user’s device
What if the user’s laptop is infected by a malware, a trojan, or a keylogger? The attacker could then steal the user’s data directly from the device memory or listen to keyboard events. Device compromise is kind of game over, since the attacker is inside the house already—and got in with a perfectly good set of keys.
Unfortunately, as a third-party app provider, 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.
Attacking our servers
An attacker could try to penetrate our servers on AWS and steal the encrypted user data files from our servers. In practice, 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 try to brute-force each of those files but that would require massive amount of computing power and time.
Server-side security hardening is a well-known activity; we do not need to reinvent the wheel. We leverage best practices from the industry and from standards such as PCI-DSS and SOC2. We benefit from the built-in security of AWS, as well as from years of investment of the tech community to improve server security. For Dashlane, it is about enforcing our zero-knowledge concept and making sure we follow those best practices closely.
Breaching our internal IT
Compromising our internal IT infrastructure is another risk. The use case here is not so much 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 a 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 things to manage, 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. (We use Duo.)
- Strong network security with breach detection mechanism. (We use a tool called Darktrace.)
- Secure and strict IT processes such as "least privilege access." (e.g. You should have access to only the systems that are required for you to do your job.)
Exploiting the human factor
That last attack vector may have a similar impact as an 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, or 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 alone could not ship a corrupted Dashlane build.
Investing in security
Investing in security is always complicated. It is like insurance. Nobody wants to pay for insurance, but you are happy to have it when something bad happens.
To include security investment in a business plan, you need to reverse the approach. What would it cost the company if a security crises were to happen?
For instance, the Equifax breach in 2017 ended up costing to them between an estimated $300 and $500M. A GDPR fine can go up to 20M€ or 4% of global revenues of a company. If you breach PCI-DSS, you could be banned from Visa and Mastercard and no longer being able to process payments.
But that investment is not only about money. It is about people and about time.
You need to train the whole company, raise the awareness so that everybody feels it is also their responsibility:
- Train employees. (Just as an anecdote, the Dropbox breach in 2012 when 68 millions user accounts were leaked came from the exploit of a Dropbox employee account. That employee had reused the same password at home and at work, and that gave the keys to the hackers to penetrate Dropbox internal infrastructure.)
- Train engineers around secure development best practices.
- Train your product managers so they embed security directly in their design.
- But also train your Execs and your Board members so they have the right level of awareness.
Conclusion
Security is a hard and complicated topic for any company. It is however a critical one considering the potential impact of a security incident, so it is important to evaluate your risks and how to mitigate them, so you can address them and hope to keep everybody safe. And most critically, security through obscurity is barely security at all, which is why we share publicly the measures we take to protect our customers and their data.
Sign up to receive news and updates about Dashlane
