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 cannot impersonate users or reset passwords; multiple engineers are required to ship an update to a Dashlane client application; 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 Minimal Security Architecture

In traditional cloud services, all user data is encrypted using a single, centrally managed key. This approach simplifies implementation but exposes catastrophic risk: If the key or the storage system is compromised, every user’s data becomes accessible.

Attack vector: Theft of the central encryption key or data store
Impact: Complete compromise of all customer data
Example outcome: A single insider or attacker with access to that key can decrypt every stored credential

7.2.2 Common Cloud Architecture

A more secure but still vulnerable model is to derive encryption keys from each user’s master password. This provides isolation between users, yet many password managers also use this same key to authenticate the user with their cloud services.

This coupling of encryption and authentication introduces several weaknesses:

• Exposure of password hashes or salts during server breaches
• Implementation errors such as missing salts or weak key derivation (e.g., PBKDF2 misconfigurations)
• 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.3 Dashlane’s Zero-Knowledge Architecture

Dashlane eliminates these systemic weaknesses by fully separating encryption from authentication:

• Vault encryption: Performed locally on the device with a key derived from the user’s Master Password or Machine-Generated Master Password.
• Server authentication: Managed through a distinct, per-device Device Key that is never shared between devices or transmitted to Dashlane servers in plaintext.

This dual-key design ensures that even if Dashlane’s infrastructure were breached and all encrypted vaults and Device Key hashes stolen, attackers could not decrypt vault data:

• Each vault would require an independent brute-force attack protected by Argon2 key stretching and per-user salts
• No centralized secret or shared key exists to compromise multiple users
• Device-based authorization prevents vault decryption without control of a previously trusted device
• Cryptographic operations in the cloud run inside isolated AWS Nitro Enclaves, protected by confidential computing attestation

Security properties:

• No Dashlane employee or system can access customer vaults, by design
• Master Passwords and derived keys never leave the device or transit in plaintext
• Separation of duties ensures server breaches do not endanger encryption keys
• 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.