Inside Dashlane’s Privacy-First Approach to Credential Risk Detection

Published:
Dashlane’s co-founder and VP of Architecture shares how we built Credential Risk Detection to give IT admins proactive insights while maintaining security and privacy.

In today’s AI-powered digital landscape, security breaches are a constant threat for organizations, and weak and compromised credentials are a common entry point for attackers.

While credential managers offer a robust security solution, user adoption rates aren’t where they need to be. Deploying any new tool, particularly one that handles sensitive information, requires careful consideration.

Our goal with our intelligent credential security platform, Dashlane Omnix™, is to provide a solution that protects all users, even those not actively using Dashlane, from the risks associated with weak and compromised passwords. These passwords remain a reality for many users, and we aim to address this challenge head-on.

Dashlane’s solution: Proactive credential risk detection

Meet Credential Risk Detection, the innovative new feature we developed that enables IT and security teams to monitor the use of weak and compromised passwords in real time, regardless of whether a user is logged into Dashlane. This ensures user privacy and security while offering IT and security teams valuable insights into their organization's overall password security posture.

Here’s how we developed Credential Risk Detection in a way that balances privacy and visibility.

Challenges of logging sensitive data

Logging sensitive data in a secure and private way, especially information related to weak and compromised passwords, presents two inherent challenges.

1. Checking for compromised passwords

Determining if a password is compromised without exposing the password itself is a major hurdle. Sending the password to a server for checking against a database would introduce significant security risks we don’t want to expose our users to. We decided to use k-anonymity to overcome this challenge.

2. Storing sensitive information

We want to avoid storing information about compromised passwords. If that data were compromised, it could be incredibly valuable to attackers, enabling them to directly target at-risk credentials. We use confidential computing and a zero-knowledge approach in the cloud to make sure this data can only be accessed by our customers.

High-level architecture of Dashlane's Credential Risk Detection

Here’s an overview of how we designed this innovative feature:

  1. Deployment: An IT admin silently mass-deploys the Dashlane browser extension, as well as a team-specific key that enables the Dashlane browser extension to authenticate and send logs.
  2. Real-time monitoring: The extension runs in the background, continuously monitoring password inputs across all websites and apps. 
  3. Risk detection: When a user enters a password, the extension performs a local security check to identify its strength and uses a k-anonymity technique to identify if the password is compromised (more on that later). An encrypted activity log with information on the password health is sent to the Dashlane cloud secure enclave through a secure channel.
  4. Secure storage: The encrypted activity log is stored in our confidential computing infrastructure in the cloud secure enclave, ensuring data confidentiality and integrity.
  5. Customer access: Only authorized IT admins with appropriate credentials can access and decrypt the logs. Nobody else can access this data.

How we securely check if a password is compromised

Sending the password to a server to check against a database would introduce significant security risks. However, downloading on clients a list of all compromised passwords’ hash would present a scalability issue.

Thus, we’re using k-anonymity to check for compromised passwords without exposing the full password itself.

This technique involves:

  1. Hashing the password: The entered password is first hashed on the user's device.
  2. Sending a partial hash: Instead of sending the entire hash, only the first k bytes are sent to Dashlane’s servers (hence the name k-anonymity). This partial hash is used as an index to identify potentially compromised passwords while maintaining the confidentiality of the full password.
  3. Receiving a list of potential matches: The server responds with a list of compromised passwords’ hash that share the same initial hash bytes.
  4. Local comparison: The final comparison between the user's full password hash and the list of potential matches happens locally on the user's device. This ensures the complete password is never exposed outside the user's device.

We use this same process to check if your Master Password has been compromised, as explained in section 1.14 of Dashlane’s Security Principles & Architecture white paper.

A diagram that shows the k-anonymity flow for Master Password check. First three bytes of the hash of the Master Password are sent to server and compared to breach databases. Server sends back a list of matching hashes. Final comparison happens locally on the device.
K-anonymity when applied to Master Password check

How we securely store the information

We rely on our confidential computing stack that we’ve been developing for awhile now.

To store the encrypted activity logs, we use a secure enclave architecture. A secure enclave is a highly isolated environment within a server that is inaccessible, including to the service provider itself. This architecture ensures the data is protected from both external attackers and potential internal threats.

Only IT admins of customers can authenticate to those secure enclaves when they want to view the logs sent by their employees.

At rest, the logs are encrypted with team-specific encryption keys. Those keys are protected by enclave keys that are managed by AWS Key Management Service (KMS) and that only the secure enclaves can query from the KMS.

Finally, all the traffic between client apps and the secure enclave is end-to-end encrypted so that no one with access to our infrastructure can read it.

A diagram that shows how Dashlane sets up a confidential computing infrastructure, leveraging a KMS, sending an enclave local key to the secure enclave, setting up the secure tunnel, sharing the enclave unseal key, and finally being able to exchange data encrypted through the tunnel between the secure enclave and the rest of Dashlane infrastructure.

Closing the loop on Credential Risk Detection

By combining mass deployment, confidential computing, k-anonymity, and AWS KMS, we provided visibility to IT admins on their users’ weak and compromised passwords. Employees don’t need to actively use Dashlane or be logged in.

Most importantly, we didn’t compromise on security: Information about employees’ weak and compromised passwords is only accessible to IT and security teams. 

Dashlane's Credential Risk Detection empowers organizations to proactively identify at-risk users without the need to onboard users to a new tool. Organizations can start their evolution toward better credential security by deploying Dashlane silently to all employees even before onboarding them to Dashlane.

We believe that proactive protection is the key to a more secure digital future, and we’re committed to leading the way.

Sign up to receive news and updates about Dashlane