Response to Reported Security Vulnerabilities (University of York)
At Dashlane, it’s our job to make the internet not only simpler but also safer for you. That’s why we built Dashlane with security at the core of our product. Recently, a report was published that analyzed a several-years-old version of our app and flagged several potential security vulnerabilities.
While we encourage analysis of our product from outside parties, and in fact work with many standards and testing organizations like HackerOne and Quarkslab (and are SOC 2 compliant), we were surprised to see a published report claiming vulnerabilities in our product based on versions of software that are many years old and not what our customers currently use, as well as presenting industry-standard user experience practices as design missteps.
Still, as our customers, we owe it to you to be transparent about design decisions and how we address any perceived or actual security vulnerabilities. This post addresses in full the considerations regarding Dashlane laid out in the paper Carr, Michael and Shahandashti, Siamak F. Revisiting Security Vulnerabilities in Commercial Password Managers.
URL mismatch, subdomain handling, and HTTP v HTTPS support
- The Dashlane app stores passwords based on the URL that the user saves. If a website is compromised in some way that sends users’ logins and passwords to a new location, that is unfortunately the responsibility of the website operator. We warn the user any time something looks amiss.
- Dashlane follows the same protocol as most major internet browsers do to establish cookie limitations, using the publicly maintained Public Suffix list to determine which domains should be allowed to be treated as a group versus being isolated as separate sites.
- Dashlane does not allow autofill on unencrypted connections to websites. A website with an unencrypted connection will have a URL that begins with HTTP as opposed to HTTPS. If a user still chooses to use Dashlane to fill a password form, we warn them first that the website is not secure.
Registration Discovery Response
- Dashlane follows similar practices to other major identity managers, including Google, Microsoft, etc. It is a modest concession to improve the user experience for our customers by confirming their account email is valid.
Element Inspection (Password Sharing)
- In short, the most secure way to share a password using Dashlane is to share it with another Dashlane user. This is explained in further detail in the following article on our Help Center: Can other people see the password I shared with them?
App PIN brute-forcing
- We always recommend that our users use a Master Password on Android devices, and we do not enable the PIN code by default. Although some of our customers prefer to use a PIN code, we do not recommend it as it is less secure than entering the Master Password or using biometric authentication. Brute force attacks are an attack vector inherent to encryption itself. In order for an attacker to enter a user’s encrypted vault, they would have to compromise a user’s device, either physically or at a user-level remotely.
We hope this post has helped answer any questions you may have. At Dashlane, we know the importance of security researchers in helping keep our community safe—which is why we have a security vulnerability reporting program. We’re committed to keeping the Dashlane app secure so all your data—and the data your passwords protect—is safe.
Sign up to receive news and updates about Dashlane
