Cet article est également disponible en Français.

Why Dashlane Cannot Be Trusted

Initially, this post should have been a comparative of password managers. However, while doing my research, I stumbled upon some concerning design choices regarding Dashlane, which pushed me to write and publish this post first.

Specifically, I take serious issue with two of Dashlane’s features, both in the way they are designed and in the way they are presented. The first feature does not respect basic security by design principles, to which any application or organisation should automatically adhere when handling sensitive data. The main principle Dashlane tramples is the minimisation of their attack surface, as their design choices make them unable to guarantee that they will never have access to their users’ passwords without knowing their Master Passwords.

Dashlane's design choices make them unable to guarantee that they will never have access to their users' passwords. Tweet this

Dashlane’s Password Changer

The main problematic feature is their Password Changer; it may look awesome, but it represents a serious security issue. Rather than doing everything locally on the user’s machine, which is what another password manager with this feature does, Dashlane does it via their servers. Their FAQ mentions the following (emphasis mine):

A “suspicious log-in attempt” notification may appear when signing in to a site after using Password Changer, because your passwords are changed through our servers when using the Password Changer feature. This is why a site may detect that you are signing in from another location and display a warning. Password Changer uses our servers to actually connect to the sites in order to update your passwords there.

You read that right: when using Dashlane’s Password Changer feature, both your old and your new password transit through Dashlane’s servers, where they will be in plain text at one point or another, since they need to be able to fill them on the website they are changing the password for. This is the exact opposite of security by design. The best way for a service to guarantee the secrecy of data is to ensure they never have access to it in the first place.

The best way for a service to guarantee the secrecy of data is to ensure they never have access to it in the first place. Tweet this

This led me to contact Dashlane to see how they intended to justify this. Their first-level support basically told me it’s secure because “information is removed from Random Access Memory right after our servers send the result back to the application, which is 45 seconds in [sic] average to change a password, or after five minutes if our servers cannot reach your application anymore”. This was in the middle of a big smoke screen on how passwords are encrypted before being sent to the server (thank goodness) and that all passwords stored in Dashlane are only known by the user and never by Dashlane. With the way they put things and the amount of technical jargon used, their replies could have easily fooled people who are not technologically inclined (the whole email thread is included at the end of this post).

The worst thing is how they continuously play with words. They told me the transmitted passwords “are only used to update your new password there, and they are not stored anywhere on [their] servers”, which is outright false since it’s stored in memory for 45 seconds to 5 minutes. What this means is any hacker or malicious employee with access to the code or servers responsible for changing passwords can easily put something in place to save transmitted passwords somewhere.

But that’s not all: they certainly have logging systems in place to keep a trace of all requests made to their servers for bookkeeping, debugging, etc. All that needs to happen is for a single employee to commit a small mistake, and all passwords end up in these logs, which is what recently happened to Twitter. This is why security by design is so important when creating a password manager: designing things in such a way that the design itself makes security threats like this virtually non-existent.

Dashlane’s help pages are no better: the language used in their explanation on how the Password Changer works is extremely misleading as well. Their base explanation does not clearly mention that the passwords are sent to their servers and I even find that it could have you believe that everything is done locally. I’ll let you judge for yourself:

Your passwords are always generated locally by the Dashlane application, and they are always transmitted securely or encrypted when updating your passwords on Web sites. All information transmitted to Web pages (including security questions and Two-Factor Authentication codes if required by a site) is done securely, just like if you were logging into individual websites yourself and changing passwords manually.

It’s only further down, in the part for advanced users—which few people will read—, that they finally address the fact that passwords are sent to their servers. If this isn’t a deliberate attempt at fooling their users, I don’t know what it is… But wait, it gets better: this feature goes against their own security principles:

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.

They say a good security architecture should never trust any server, code or user it interacts with, including Dashlane’s servers, yet trusting their servers and code is exactly what they’re doing here.

This feature goes against their own security principles. Tweet this

My suggestion is they simply remove this feature while they work on creating a version that works entirely locally. However, I do wonder if it’s even relevant to keep such a feature because its only real purpose is to cause a “wow-effect”. It is indeed not that useful, given there are only two reasons to change a password:

  1. If you suspect the password has been discovered by someone or something that shouldn’t have;
  2. If your password is insecure (or in other words, if it was generated with something other than a password manager).

If you’re already using a password manager, the second point is never going to be an issue. Regarding the first, I would say this doesn’t happen often enough to justify having a tool to change them automatically. The only case where this can really come in handy is when you start using a password manager for the first time, meaning you’ll have to change all your passwords. With that being said, you will need to add your accounts one by one anyway, so you can just change your passwords at the same time. Moreover, Password Changer only supports a limited number of websites and the vast majority of big players seem to be missing: Google, Apple, Microsoft, Facebook, Amazon, GitHub, Spotify, Dropbox, LinkedIn, Steam, CloudFlare, Uber and PayPal are all absent from the list of supported websites. The only known websites I saw are Netflix, IMDb, Indeed, ProtonMail, Reddit, Vimeo, Yelp and some press websites. All the others were small websites, most of which I have never heard of. In short, it’s not all it’s cracked up to be. Do note that I doubt the lack of support for Google and others is Dashlane’s fault; it’s probably due to their security preventing automated password changes in one way or another, but it does make the Password Changer all the more useless and demonstrates its purely commercial nature.

Dashlane’s reluctance to recognise this issue does not help their case; I had to insist quite a lot to eventually get redirected to their second level support, which finally acknowledged the issue, telling me they tried to do it locally, but it ended up being too slow so they chose to do it via their servers. The mistake here was to go with an intermediate solution instead of waiting until they manage to create something that works entirely locally. This really looks like upper management strong-arming a reluctant technical team that is dissatisfied with their solution, under the pretext that “they’re not going to throw away working code” and that “hacks and malicious employees only happen to others anyway”.

Dashlane’s Password Sharing

Dashlane also offers a feature that allows its users to share passwords. This password sharing has two modes: one which allegedly only permits someone to use the password (limited rights), while the other one allows them to use it, see it, modify it, share it further or even revoke the access of other users who have access to it, including the person who shared it with them (unlimited rights). Aside from that last rather strange point, the issue is that their FAQ tries to have you believe the limited mode makes it impossible to view the password, which is flat out false.

Can other people see the password I shared with them?

Yes, depending on which permission settings are chosen when sharing an item. There are two different permission settings for password sharing:

  • Limited Rights: The recipient can only use this item.
  • Full Rights: The recipient can use, view, edit, and share this item. They can also edit sharing rights and revoke sharing rights of other users who were shared this item, including yours.

Be sure to choose Full Rights if you require the users to be able to view and edit the contents of these items.

It is impossible to guarantee that a person cannot view a password they can use, because accessing it is trivial using the inspector of their browser to:

  1. Modify the password field so it becomes a text field, before filling it with Dashlane;
  2. Inspect the login request that was sent, by using the network tab.

The first vulnerability can be fixed by preventing Dashlane from filling passwords in anything other than password fields, but the second one is simply unfixable. This is why I suggest Dashlane simply allow people to view passwords that were shared with limited rights, so as to avoid any ambiguity and false sense of security. At the very least, they need to correct their FAQ to clarify this.

On top of that, note that this issue was already communicated to them more than a year ago, yet they still haven’t fixed it. I took this up with their second-level support and was told my feedback would be transmitted to the team to make sure they are aware of the risks I mentioned and see what can be done. Given the whole honesty situation, go figure if this was an honest answer or just an attempt at damage control…

Conclusion

The issues laid out above clearly show that Dashlane prefers generating a “wow-effect” instead of guaranteeing the security of their users’ data 120%. The fact that they go against their very own security principles is also deeply concerning. I really hope Dashlane will modify these two features in the future, because without the aforementioned issues, Dashlane would have been a viable choice.

With that being said, even if they end up fixing these issues, I doubt I would be able to trust them, given the misalignment between the interests of their management and the interests of their users. It’s either bad management directly or incompetence on a technical level, but in the end, their management would be at fault for both of these, because a bad technical team doesn’t just magically appear. Most of all, this is really concerning, because the end result is a password manager whose basic design has flaws, with dubious help pages and incompetent first level support, which both try to muddy the waters.

Below, you will find the complete, commented email thread between me and Dashlane, which is really worth a read. If you’re a Dashlane user and don’t know which password manager to turn to, or if you’re not using one yet, check out my post comparing the major players on the market.

Emails Exchanged with Dashlane

Hi,

I have recently started comparing password managers to see which one is currently the best on the market. While looking into Dashlane, I stumbled upon your Password Changer feature. Intrigued by it, I dug a little deeper, which is when I found this in your FAQ: “Password Changer uses our servers to actually connect to the sites in order to update your passwords there.”

This means that both the old and the new password are in clear text on your servers at one point or another, since you need to be able to fill them in the forms on the website you’re changing the password for. Would you mind explaining how I should trust the Dashlane team if they think that this is secure? This seems to be the exact opposite of security by design and just begs to be hacked or accessed by a malicious employee.

Best regards,

Pierre-Louis

The first reply came in ten hours later:

Hi Pierre,

Thank you for contacting us and I hope you are doing well!
This is Alex from Dashlane’s Support team and I will be assisting you with your inquiries.

Please allow me to explain how Dashlane’s Password Changer works.

The passwords being generated by the Password Changer are always generated locally by the Dashlane application, and they are always transmitted securely or encrypted when updating your passwords on Web sites. All information transmitted to Web pages (including security questions and Two-Factor Authentication codes if required by a site) is done securely, just as if you were logging into individual websites yourself and changing passwords manually.

Note that your passwords – exclusively when using Password Changer – are securely encrypted and transmitted to our servers. They are only used to update your new password there, and they are not stored anywhere on our servers. Only Password Changer works like this. All your account data is encrypted using your master password and made unreadable to anyone, even by us.

Additionally, any sensitive information on our servers (e.g. logins and passwords when signing to sites) is only used temporarily in Random Access Memory. Random Access Memory is a volatile type of memory used as a working space and constantly overwritten with other data – their state is also lost or reset when power is removed from the system. All information is removed from Random Access Memory right after our servers send the result back to the application, which is 45 seconds in average to change a password, or after five minutes if our servers cannot reach your application anymore and confirm that the password was changed during the process. This information is never stored on our servers.

Only you know your passwords. They are only saved in your Dashlane account, which is protected using your master password and secure AES-256 encryption. No one has access to your data in your Dashlane account except you - not even us at Dashlane!

You can also refer to this article which gives advanced explanations on How Password Changer works.

If you would like me to clarify anything else, please let me know. I’m happy to help in any way I can.

Have a great day!
Kind regards,

Alex
Dashlane Customer Support

The language in this email really tries to muddy the waters by putting buzzwords everywhere and speaking of secure parts of the application that are not related to the Password Changer in any way. I found this really concerning, so when I received an email asking to rate the support I received, I let them know I was unhappy with their response. A few minutes later, I received this:

Hi Pierre,

It’s me again, Alex from Dashlane Support Team! I just want to check on you. How’s it going? Do you need any further assistance?

I was able to receive your response using our satisfaction rating tool, and it seems like you are still needed our assistance.

I’m sorry to hear that you don’t find my explanation clear and helpful. Please allow me to explain again how Dashlane’s Password Changer works.

This is how it works: When you request to use the Password Changer, Dashlane is logging in directly to these sites then generate a strong and unique randomly generated password for you and change the password the site on your behalf locally.

All passwords being sent over to our servers are all encrypted using your master password and secure AES-256 encryption - a Military Grade Encryption. No one has access to your data in your Dashlane account except you - not even us at Dashlane!

Additionally, any sensitive information sent over to our servers (e.g. logins and passwords when signing to sites) are encrypted and stored temporarily.

To my understanding with your feedback is, you do see a problem with this process. Do you mind providing with us with additional details?

Thank you very much in advance for your response! I look forward to further assisting you.

Please feel free to get back to me for any question or clarification.

Kind regards,

Alex
Dashlane Customer Support

As is the case in their FAQ, he uses dubious language that would have you think passwords are changed locally, when in fact that isn’t the case, as he mentions himself later. In addition to that, he’s still swinging buzzwords such as “Military Grade Encryption” around, and even asks me to explain why I see a problem with their way of doing things, which I already did in my first email. This really annoyed me, so I replied this:

Hi Alex,

Well yes, I am dissatisfied with your response and this one unfortunately fed my dissatisfaction even further. You are, yet again, throwing all kinds of buzzwords around and speaking of unrelated things. I’m well aware that Dashlane’s password databases are encrypted using AES-256 encryption and that this makes user passwords stored in Dashlane inaccessible to Dashlane, but that’s not the point.

The point is that when using the Password Changer, user passwords are at some point accessible to Dashlane and anyone who has access to the servers that handle the password change in itself, be it employees or a potential hacker. The password is only encrypted en-route to the server, whereas when it is temporarily stored in RAM while it’s being changed, it is necessarily unencrypted, otherwise you wouldn’t be able to fill it into the forms on the website. This is a huge security risk, because it makes the probability of someone accessing a user’s password because of Dashlane non-zero, while it should be… well… zero. This is the opposite of security by design, which is what a password manager should always adhere to.

Best regards,

Pierre-Louis

15 minutes later, I got this response:

Hi Pierre,

Thanks for writing back and for your feedback.

To better assist you with your inquiry, I will be escalating your concern to a higher level of support.

Kindly wait for the email that you will receive from them.

I appreciate your patience about this inquiry, rest assured that we will do our best to meet your expectations.

Still, have a great weekend! Best regards,

Alex
Dashlane Customer Support

At last, some hope of getting a decent response. I did have to wait three days, but I ultimately got a more sensible and moderate reply:

Hello,

Thank you for your patience. I am Edgar from the Dashlane technical support team and I am here to help you.

I can confirm that the passwords that are changed using Password Changer are indeed updated using our servers and not locally by the application.

The reason why we designed this is to enable multiple passwords to be changed in seconds, which would be less reliable if your computer had to do it, considering many of our users also use mobile devices or may have a bad Internet connection.

Our team is aware that it would be much better to do everything locally, and we plan to work on improving Password Changer in the future to offer a reliable and quick way to change all your passwords locally in seconds.

Unfortunately, the tests we ran for this were not satisfactory enough in terms of performance and reliability and this is why we chose this intermediary solution, which is using one of our servers and working on offering the best security.

Because of this, I can confirm that the Dashlane servers have temporarily access to your current password and the newly password to sign in to the site and change the password there using Password Changer.

We designed this feature with security in mind, and detailed in our documentation on Password Changer, this information is securely transmitted and use a separate server infrastructure, as well as dedicated instances and distinct security groups.

Any sensitive information on our servers is only used temporarily and removed right after our servers sent the result back to the application, which is 45 seconds in average to change a password. Your passwords are never stored on our servers.

I understand your concerns and I have passed your feedback along to the rest of the team.

If you have any other questions related to this feature or would like me to clarify anything else, please let me know.

Kind regards,

Edgar
Dashlane Customer Support

I was happy to see that they finally acknowledged the issue, as well as knowing that they are trying to change things to do this locally. However, I still take issue with the fact that they delivered something that doesn’t guarantee the security of their users 120%. This is when I suggested they disable the Password Changer while they work on a solution to make this work locally, while also mentioning the issues with their password sharing. Here’s my response:

Hi Edgar,

Thank you so much for this email, which finally acknowledges the issue​​​. The thing I still have an issue with is that your management still chose to go with a feature that isn’t 120% secure. You should just have gone without a password changer while you took the time to find a way to make it work locally. I definitely understand that you tried to design this in such a way that it would be hard for any leaks to happen, but you’re still making a 0% probability a non-zero probability, which is an issue for a company handling sensitive data. This is bound to go wrong at some point or another. I would suggest disabling Password Changer while you find a solution that works locally. At the very least, the documentation on Password Changer​ should be updated so that the part for “normal” users acknowledges the fact that the passwords are changed through your servers, because the language ​there is a quite misleading and to me it almost feels like it’s on purpose. Most people won’t read the part for advanced users, so they won’t necessarily know it’s done via your servers​ and have a false sense of security​.

I also believe part of your password sharing feature needs changing. The FAQ tries to make people believe that if they grant limited rights, the person the password is shared with cannot view it under any circumstances, but that’s completely false and misleading. All the person needs to do is go to the website the password was shared for, open their inspector, log in and check out the password in the network tab. They can also just change the password field into a text field and view it directly in there. Given this, my first suggestion is to change the FAQ to make this clear to your users while you work on my second suggestion, which is allowing people to view passwords even if they were shared with limited rights, in order to avoid any ambiguity. I also think your full-rights sharing needs tweaking, because it just seems weird to me that a person with whom a password was shared would be able to revoke the access of the person who shared it with them, no matter their rights. The only case where this would be normal is a password transfer, so perhaps you could implement something that allows people to transfer passwords to another user directly and remove that part from the password sharer.

Best regards,

Pierre-Louis

I got a reply the next day:

Hello Pierre-Louis,

Thank you for your reply.

I have read and understand you point of view. I will pass on your feedback on to the team for them to be aware of the risks you mention with the Password Changer and Sharing features and see what can be done.

Please do not hesitate to get back to me if you have other questions.

Kind regards,

Edgar
Dashlane Customer Support

Whether this is an honest reply or just damage control remains yet to be seen.

Thank you for taking the time to read this post.
If you enjoyed it, perhaps share it with people you know?

If you wish, you can also support the writing of these posts.
Subscribe or follow me on social media using the buttons below.

Comments

comments powered by Disqus
Subscribe

Want to receive an email every time we publish something new? Leave your email below.

We hate spam as much as you do.