Edit 24/01/23 : This article is outdated, the current cryptography settings are detailed in our Security White Paper
Security at Dashlane has always been a very strong focus of our Engineering team. As a leading password manager, Dashlane is responsible for the safety of the data of millions of users. In order to protect our user’s’ data, we take security into account at every stage of our software development, including the design of our architecture, coding and code reviews, tests, and security audits; security is also a major factor in our product specification, design, communication, and documentation.
When we started the development of Dashlane, we had to design how our users’ data would be protected. We began with a list of all the criteria that a good security model should have. Here are the three most important criteria we came up with:
1. Simplicity: An essential key aspect of any security architecture is its simplicity. A simple security architecture is easier to review, both by developers and by security researchers. It is also easier to understand globally and allows developers to modify it without having blind spots.
2. Do not trust anything or anyone: We believe that good security architecture should never trust any server, code, or user it interacts with, including Dashlane’s servers. Even if we do everything we can to ensure our servers’ safety, we always work with the assumption that our servers could become the next target of a cyber criminal at any time; our architectural choices must ensure that such an event, however unlikely it may be, does not break our security model.
3. Resilient against common and known attacks: Security breaches happen every day. A good security model would need to be naturally resistant against common attacks and breaches, for instance, against usernames and password hashes leakage, which are very common targets of cyber attackers. In addition, the simplicity of the security model makes it easy for the world-class security team at Dashlane to continually monitor for recent attacks and vulnerabilities and ensure that Dashlane’s architecture is protected from any new exploits.
From Day 1, we designed our security model to meet or surpass all of those criteria, and in March 2012, we submitted a security patent to the U.S. Patent and Trademark Office (USPTO) under the title “Cloud-based data backup and sync with local storage and access keys”. During this time, we had several back and forth with USPTO to amend our initial claims and description to ensure it captured the latest state-of-the-art and non-replicable technology, which culminated in the awarding of a patent in February 2016. Here’s a quick rundown on our patented technology which works by separating a user’s authentication process from their data ciphering process.
User data ciphering process
The algorithm used to cipher a user’s data is very simple and uses well-known standard practices. From a user’s Master Password, we derive a ciphering key using 10000 PBKDF2 iterations, and we use AES-256 to cipher a user’s passwords, payment information, and/or personal information that is stored within Dashlane. Any stored data is always encrypted into an indecipherable string of random letters, numbers, and symbols, which is stored locally and also on Dashlane servers for synchronization purposes. However, for your protection, as well as our own, we never store your Master Password or any of its derivatives on our servers at any time.
User authentication process
User authentication is required in addition to ciphering a user’s data. For instance, if I log into Dashlane for the first time on a new computer, I need to have a way to prove to Dashlane servers that I am Guillaume Maron, so Dashlane’s servers can provide me with my ciphered data.
Considering that a lot of cyberattacks are targeting users’ password hashes, we did not want to rely on users’ Master Password hashes to authenticate. Instead, when a user logs into Dashlane for the first time on a new device, they are always prompted to enter a One Time Password (OTP) sent by email. During this first connection, a User Device Key is generated and sent to Dashlane’s servers to establish a trusted authentication link. As a result, in order to access a user’s data, an attacker would need to possess both the user’s Master Password, and also have access to one of his/her devices or access to his/her email.
We’re committed to continuously improving the security of Dashlane while maintaining these fundamental principles. If you want to know more, don’t hesitate to check our Security page with our Security White Paper or contact me at security@Dashlane.com.