Internal note: Notify of changes

7.1 Overview of Dashlane’s threat model

Dashlane’s approach to threat modeling follows the principle of assumed breach:
We assume that any layer, client, network, or backend, could be compromised, and we architect the system to contain and neutralize those risks.

We categorize potential threats into five primary classes:

Figure: Dashlane Threat Model

1. Compromise of Dashlane applications
   • Risk: Exploiting vulnerabilities in our browser extension, mobile, or desktop apps
   • Mitigations: Secure SDLC, static and dynamic analysis, dependency scanning, formal threat modeling, penetration testing, and a public bug-bounty program
2. User device compromise
   • Risk: Malware, keyloggers, or OS-level exploits capturing user inputs or decrypted vault data
   • Mitigations: Local AES-256 encryption, Argon2 key derivation, memory obfuscation, and passkey-based phishing-resistant authentication; vaults are only decrypted in volatile memory, and sensitive data is wiped after use
3. Server or infrastructure breach
   • Risk: Attackers gaining access to backend systems or databases
   • Mitigations: Zero-knowledge design ensures encrypted vaults are useless without local keys; confidential computing enclaves (AWS Nitro Enclaves) isolate cryptographic operations so even an infrastructure compromise yields no plaintext data
4. Insider or supply chain attack
   • Risk: Unauthorized access through compromised build pipelines or privileged insiders
   • Mitigations: Segmented infrastructure, least-privilege access, MFA on all admin systems, code-signing verification, reproducible builds, and continuous integrity checks; no employee has the technical capability to decrypt a user vault
5. Social engineering and human-factor exploitation
   • Risk: Phishing, coercion, or insider manipulation
   • Mitigations: Dashlane employees can't impersonate users or reset passwords; multiple engineers are required to ship an update to a Dashlane client app; Dashlane employees undergo regular security awareness training

7.2 Comparative security architectures

The following sections illustrate how Dashlane’s zero-knowledge architecture improves upon legacy and common password manager designs, mitigating the primary risks of centralized encryption and authentication coupling.

7.2.1 Architecture coupling encryption and authentication

In legacy cloud services, all user data used to be encrypted using a single, centrally managed key. This approach simplified implementation but was exposed to catastrophic risk: If the key or the storage system was compromised, every user’s data would become accessible.

A more secure but still vulnerable model is to derive encryption keys from each user’s Master Password. This provides isolation between users, yet some solutions rely solely on this same key to authenticate the user with their cloud services, without incorporating additional authentication mechanisms.

This coupling of encryption and authentication introduces several weaknesses:

• Exposure of password hashes or salts during server breaches
• Brute-force feasibility if user Master Passwords are weak or reused

Attack vector: Server compromise or credential reuse leads to vault decryption attempts
Impact: Partial data exposure; each user’s vault must be attacked individually, but at a lower computational cost

7.2.2 Dashlane’s zero-knowledge architecture

Dashlane eliminates these systemic weaknesses by implementing a multi-layer authentication:

• Verifying email access: When a user attempts to connect to a Dashlane account on a device that has not yet been authorized for that account, Dashlane generates a One-Time Password (OTP, or token) and sends it to the user to the email address used to create the Dashlane account initially.
• Verifying encryption key knowledge: Then, the OPAQUE protocol allows the client application to prove to the servers that the user knows the encryption key. Throughout this process, OPAQUE guarantees that the servers gain no knowledge of the encryption key itself.

This design ensures that even in the case where an attacker has access to the user Master Password, the user's data stays protected.

Security properties:

• No Dashlane employee or system can access customer vaults, by design.
• Master Passwords and encryption keys never leave the device or transit in plaintext.
• Even under a complete infrastructure compromise, user vaults remain cryptographically opaque.

7.3 Clickjacking & cross-site attacks

Dashlane integrates with browsers but enforces strict controls to prevent websites from triggering unauthorized actions.

Defenses:

• Same-origin policy: Credentials saved for one domain cannot autofill on another.
• HTTPS-only autofill: Dashlane never autofills credentials on non-secure (HTTP) sites.
• Anti-clickjacking: Pop-ups and autofill prompts cannot be controlled by page JavaScript, ensuring users must perform explicit actions.
• Content-Security Policy (CSP): Enforces browser-level boundaries for web extension components.

7.4 Memory attacks

If an attacker gains full control of a device, they might attempt to read vault contents from memory.

While no application can fully defend against a rooted or jailbroken environment, Dashlane minimizes risk through:

• Volatile decryption: Vault data exists only in RAM during active sessions.
• Automatic memory wiping: Sensitive buffers are zeroized on logout or app lock.
• OS-level isolation: Mobile operating systems prevent inter-process memory reads.
• Hardware protections: Use of secure enclaves (e.g., iOS Secure Enclave, Android TEE) for cryptographic operations.
• Confidential computing: Extends these protections to the cloud for cryptographic workloads.

Even under extreme conditions, a rooted device, a compromised OS, or a server breach, Dashlane’s layered defenses maintain data confidentiality

7.5 Protection of public keys

When a user shares an item in Dashlane, the item’s symmetric encryption key is encrypted with the recipient’s public key. Only the recipient’s corresponding private key can decrypt the item key and access the shared data.

This ensures:

• End-to-end encryption of shared content.
• Dashlane cannot decrypt shared items.
• Access is cryptographically restricted to intended recipients.

To encrypt for a recipient, the sender’s client retrieves the recipient’s public key from Dashlane’s service.

As with most server-mediated end-to-end encrypted systems, this creates a structural dependency on the authenticity of the public key directory. If a highly privileged attacker were able to compromise the service and substitute a recipient’s public key, the sender could unknowingly encrypt data to an attacker-controlled key. This is commonly referred to as a key substitution attack.

Strong, user-verifiable public key authentication at global scale remains a difficult industry-wide problem. There is no broadly adopted solution that delivers strong cryptographic guarantees without introducing usability, operational, or additional trust trade-offs.

Dashlane mitigates this risk through hardened infrastructure, strict access controls, and continuous monitoring.

Dashlane does not currently provide user-facing public key fingerprint verification in standard sharing flows. We do not claim independent, user-verifiable authentication of recipient public keys.

Dashlane is actively evaluating advanced approaches such as Key Transparency and related mechanisms. These techniques aim to make public key directories auditable and tamper-evident, reducing reliance on implicit server trust while preserving usability.

Any adoption will be carefully assessed against our requirements for security, privacy, performance, and user experience.

Security is an ongoing process. We are transparent about the boundaries of our current design and committed to strengthening public key authenticity over time.

7.6 Transaction replay and vault integrity

Dashlane’s synchronization model relies on encrypted transactions stored and processed by the server. These transactions allow clients to reconstruct the current state of a user’s vault and enable recovery in case of device loss or local failure.

Security research has noted that because transaction keys are not uniquely bound to each individual transaction, a malicious server could theoretically replay, reorder, or drop encrypted transactions without immediate client-side detection.

This class of issue represents an integrity risk, not a confidentiality breach.

• It does not allow the server to decrypt vault data.
• It does not expose secrets or cryptographic keys.
• The potential impact is limited to inconsistent state or loss of items.

In the most extreme scenario, a compromised server could cause a vault to reflect an earlier or altered state by manipulating the transaction history.

Dashlane explicitly accepts this risk as part of a broader architectural trade-off.

The transaction-based model enables:

• Reliable multi-device synchronization
• Recovery of historical data
• Restoration of customer vaults in real-world corruption or failure scenarios

The same properties that allow replay at the protocol level also allow us to preserve and reconstruct vault history for user protection and operational resilience.

7.7 Enumeration attacks

Enumeration occurs when an attacker tries to discover whether a specific email address or domain is associated with a Dashlane account or organization by observing differences in server responses across different flows and screens. 

Dashlane protects against this type of attack by ensuring that all public endpoints return the same response, regardless of whether the submitted email corresponds to an existing account or not. The user flow proceeds only after the user proves they own the email address, using a verification token or a second factor from an authenticator application.

Endpoints called at the beginning of the flows are protected by captcha solutions to prevent automated discovery attacks through bots. These defenses ensure that an attacker cannot confirm account existence, even at scale.