Internal note: Notify of changes

3.1 Zero-Knowledge Architecture

All vault data is encrypted before leaving the user’s device and can only be decrypted locally. Neither Dashlane nor any third party can access, read, or recover the contents of a vault.

Here is an overview of how this zero-knowledge architecture is applied to critical flows. More details will be provided in subsequent chapters.

Strong Encryption

• Each individual’s vault is encrypted with AES-256-CBC + HMAC-SHA256 before storage on Dashlane’s servers.
• Decryption requires either:
  • A Master Password, known only to the user, or
  • A hidden Machine-Generated Master Password for passwordless users
• The vault encryption key derived from one of these factors is never transmitted to Dashlane or stored on our servers in plaintext. Therefore, Dashlane will never be able to decrypt users’ vaults.

Device Authentication

Each device accessing a Dashlane vault must be explicitly verified and bound to the user through a User Device Key. This ensures that even if credentials are stolen, an attacker cannot access vault data without control of an authorized device.

• New account or new device setup:
  When a user creates a new Dashlane account or enables an additional device for data synchronization, Dashlane verifies the identity of the account holder. This verification is completed by sending a one-time token to the registered email address or mobile number, after which the system auto-generates a unique User Device Key.
• Passwordless login flow:
  For passwordless users, the process is even more secure: Authorizing a new device requires approval from an already registered device. This eliminates reliance on email, which can be vulnerable to interception or account takeover.

Defense in Depth for Access

• Decryption on the device:
  When a user enters their Master Password in the Dashlane app (or uses passwordless authentication), vault data is decrypted only within the memory of that authorized device. Vault data is never decrypted on Dashlane’s servers.

• Users can strengthen security with two-factor authentication (2FA) using TOTP Authenticator applications. Enabling the 2FA option at each login means that both the Master Password and the authenticator code are necessary for decrypting the vault.
• All communications between devices and Dashlane servers are secured using TLS cryptographic protocols.

Account Recovery

Dashlane provides recovery mechanisms that preserve zero-knowledge design while enabling continuity:

• Account recovery key (ARK): Available for both Master Password and passwordless accounts, this single-use key allows secure self-service recovery without weakening encryption guarantees.
• Biometric recovery on mobile: Available for Master Password accounts only. Allows a user to reset their Master Password using their face/fingerprint on a mobile device if they forget their password.
• Admin-assisted recovery: Business admins can approve recovery requests via the Admin Console, acting as a trusted verifier of user identity.

3.2 Encryption Model: Secrets and Protections

Dashlane’s encryption relies on distinct, purpose-scoped secrets. This separation of concerns ensures that a compromise of one element does not expose the vault data and authentication mechanisms at the same time.

Table 1: Dashlane Secrets Overview

3.2.1 Deep Dive on Key Secrets

Dashlane’s encryption model relies on multiple secrets, each strictly separated by purpose. This design prevents any single compromise from exposing user vault data or authentication channels. Below are detailed explanations of the most critical secrets.

User Master Password (UserMP)

• Strength validation: Dashlane uses the zxcvbn library to validate UserMP strength. The library analyzes the chosen password against multiple patterns (common passwords, dictionary words, keyboard patterns, complexity rules) and returns a score between 0 and 4:
  • 0: Too guessable
  • 1–2: Weak to moderate strength
  • 3–4: Safely unguessable (estimated 10⁸–10¹⁰ guesses required)
• Enforcement: Dashlane applications enforce a minimum score of 3, ensuring users select sufficiently strong Master Passwords. Feedback is provided to help users improve weak choices.
• Storage and transmission:
  • The User Master Password is never sent to our server in plaintext; therefore, Dashlane will never be able to decrypt users’ vaults.
  • Not stored locally by default; used only transiently to decrypt local files.
  • Optional encrypted local storage if the user enables “Remember my Master Password.”

Machine-Generated Master Password (MachineGeneratedMP)

• Purpose: Alternative to the UserMP, used in passwordless accounts
• Generation: A strong, unique 40-character string (~243 bits of entropy) generated using Dashlane’s Password Generator
• Storage and transmission:
  • Never stored on Dashlane servers, nor are any derivatives
  • Not stored locally by default, except when logging in to the web extension
  • Never transmitted over the internet; only the encrypted vault is sent
• Security advantage: Machine-generated values eliminate human weakness (e.g., predictable passwords) and guarantee a high entropy

Intermediate Key

• Purpose: Used in certain local storage scenarios to strengthen the protection of encrypted files
• Generation and use: Random 32-byte value generated locally on the device
• Protection: Stored encrypted with a derivative of the UserMP
• Design principle: Adds another layer of defense so that one compromised key (e.g., through local device access) is insufficient to unlock vault data

User Device Key (DeviceKey)

• Purpose: Authenticates each device to Dashlane servers; prevents vault access from unauthorized devices, even if credentials are known
• Generation: Generated server-side for each new device linked to an account
• Storage: Stored locally, encrypted within user data.
• Security advantage: Separation of vault encryption (UserMP or MachineGeneratedMP) from device authentication ensures that vault compromise does not imply server compromise, and vice versa

3.2.2 Local Access to User Data

Access to a user’s encrypted vault requires the User Master Password (UserMP) or, in the case of passwordless accounts, the Machine-Generated Master Password (MachineGeneratedMP).

• Vault key derivation:
  • The UserMP (or MachineGeneratedMP) is used to derive a 256 bits key that encrypts and decrypts vault data using AES-256-CBC + HMAC-SHA256 locally on the user’s device.
  • In passwordless flows, the MachineGeneratedMP is not exposed to the user; it is transported securely between devices during enrollment of a new device, and then functions identically to the UserMP for key derivation.
• Cryptographic libraries:
  • Dashlane uses the Web Crypto API for browser-based clients.
  • On mobile, Dashlane relies on native cryptographic libraries for iOS and Android.
  • For key derivation, Dashlane implements the Argon2 reference library, compiled to WebAssembly (for browsers) or linked directly into the mobile applications.
  • Dashlane also supports PBKDF2 as a backward compatibility option for old devices. This support will be deprecated in 2026. 

Our approach ensures that all cryptographic operations happen locally, using hardened and well-vetted primitives, with no exposure of sensitive material to Dashlane servers.

3.2.3 Local Data Usage After Decrypting

Once a vault has been decrypted—after the user provides their Master Password or validates their MachineGeneratedMP through a PIN code, biometric authentication, or a security key—data is handled under strict constraints to balance usability with security:

• Session-limited decryption:
  User data is only decrypted into volatile memory and never written back to persistent storage in plaintext.
• Secure automation:
  Dashlane processes individual credentials in memory to autofill them into websites and apps or to save new credentials, without requiring the user to re-enter their Master Password or MachineGeneratedMP each time.
• Key-stretching defense:
  Derivation of AES key from the UserMP (or MachineGeneratedMP) employs Argon2d (or PBKDF2 in fallback cases). These algorithms introduce computational latency by design, making brute force attacks significantly more expensive for attackers while remaining acceptable for legitimate users.
• Memory protection:
  The decrypted data in memory is protected by leveraging pre-existing, platform-level safeguards (detailed in 7.4 Memory Attacks), ensuring that exposure is minimized even in the event of device compromise.

3.3 Devices and Authentication

Dashlane uses a device-based authentication model to ensure that only verified devices can access user vaults, without ever relying on or transmitting a user’s Master Password or Machine-Generated Master Password.

When a user creates an account or adds a new device for data synchronization, Dashlane generates a User Device Key (DeviceKey) composed of 40 random bytes using the OpenSSL RAND_bytes function. The first 8 bytes form the access key, while the remaining 32 bytes form the secret key. This DeviceKey uniquely binds each device to the user’s account.

• Local protection: The DeviceKey is stored locally within encrypted user data, protected by the vault encryption mechanism.
• Server protection: On Dashlane servers, the secret key component is encrypted at rest, ensuring that employees or attackers cannot easily impersonate a legitimate device.
• Independent from vault credentials: Authentication to Dashlane servers use only the DeviceKey, never the User Master Password or Machine-Generated Master Password.
• Frictionless experience: Once the user has unlocked their vault locally, Dashlane uses the DeviceKey for server authentication, enabling synchronization and cloud-based features without requiring further user input.

This design provides secure, password-independent authentication between user devices and Dashlane’s infrastructure, maintaining zero-knowledge architectures while simplifying the user experience.

3.4 Communication Security

All communications between the Dashlane application and Dashlane servers are protected by modern transport security protocols. Dashlane enforces HTTPS/TLS across all endpoints, with the dashlane.com domain HSTS-preloaded to prevent protocol downgrades on any subdomain.

• TLS best practices: Cipher suites and protocol configurations are regularly updated to align with current industry standards and security recommendations.
• Beyond transport security: While HTTPS/TLS provides a strong baseline protection, Dashlane’s design ensures that data confidentiality does not depend on the transport layer. Because vault data is end-to-end encrypted, even if the communication channel were compromised, an attacker would gain access only to encrypted ciphertext.

This layered approach to communication security preserves zero-knowledge guarantees while maintaining compatibility with enterprise security frameworks and modern web infrastructure.

3.5 Confidential Computing & Secure Enclaves

Enterprises require solutions that deliver both security and operational transparency when integrating with third-party systems, such as identity providers, and managing sensitive cryptographic operations. Dashlane uses confidential computing to meet these B2B requirements, ensuring that even when customers rely on Dashlane-hosted components, such as our SSO integration, data remains fully protected from both Dashlane and external parties.

Confidential computing establishes a trusted execution environment (TEE/secure enclave) that isolates data and code at runtime. In Dashlane’s implementation, this ensures that encryption keys, SSO tokens, and authentication flows are processed in cloud secure enclaves that even cloud administrators cannot access.

3.5.1 Secure Enclaves at Dashlane

Dashlane leverages AWS Nitro Enclaves to isolate cryptographic materials and protect sensitive operations from exposure, even if the host infrastructure were compromised.

• Isolated execution: All encryption and decryption operations occur inside secure enclaves, separate from the host operating system and administrative layers.
• Attestable integrity: Each enclave generates a verifiable attestation, ensuring that only trusted code is executed and that no unauthorized changes can occur.
• Confidential processing: Enclave data and memory remain inaccessible to Dashlane personnel or any external process, reinforcing the zero-knowledge architecture.
• Lifecycle assurance: Enclave creation, execution, and destruction are verifiable, providing strong guarantees of code integrity throughout the operational lifecycle.

Our security model leverages AWS Nitro Enclaves as the foundational isolation layer for our confidential computing environment. While Dashlane operates on strict Zero-Knowledge principles, the integrity of our processing relies on the AWS Nitro System. The Nitro Hypervisor creates a logically isolated compute partition, which effectively eliminates administrative access and persistent storage. Our reliance is specifically on AWS’s architectural claim that the Nitro Card and Hypervisor maintain a 'no-operator-access' environment. Crucially, our threat model acknowledges that our security guarantees are tethered to this logical isolation rather than relying on a Trusted Execution Environment (TEE) independent of the cloud provider's firmware, even as we use Cryptographic Attestation to verify our code’s integrity.

This architecture ensures that even if infrastructure is compromised, cryptographic keys and user data remain secure through an isolated workload and attested trust.

To block unauthorized access, the enclave requires authentication via its attestation to access cryptographic material. This validation is managed by a Key Management Service (KMS).

Upon authentication, each enclave instance performs two retrievals:

1. Key Management Service (KMS): Retrieves an Enclave Local Key (ELKey)
2. Internal secret manager: Retrieves an Enclave Unseal Key (EUKey)

These two keys are then combined and used to decrypt the Enclave Encryption Key (EEKey) as described in the following schema:

Figure: How keys are used to decrypt the Enclave Encryption Key

3.5.2 Enclave Workflows

The enclave operates through a series of secure workflows that govern initialization, storage, and all other operations related to the features that leverage them.

Cryptographic materials 

Enclave Initialization

During initial deployment, the enclave requests the Enclave Master Key (EMKey) from the KMS, which grants access only to verified enclaves via attestation. The KMS generates an Enclave Local Key (ELKey) and returns two encrypted versions: one encrypted by EMKey and the other by an ephemeral enclave public key. The enclave stores only the encrypted ELKey, ensuring it is never available in plaintext outside the secure environment. When the enclave restarts, the KMS decrypts the ELKey using EMKey, reestablishing a secure state.

Figure: Enclave initialization

Storage and Key Management

Because enclaves lack persistent storage, all data leaving the enclave is encrypted before transmission as described in the following sequence diagram:

Figure: Data encryption before transmission

The Enclave Encryption Key encrypts the set of encryption keys for features operated by enclaves, as:

• SSO Service Provider keys: An encryption key is generated per team to encrypt the User ServiceProvider Keys at rest (outside of the enclave); these are the keys sent back to the clients to decrypt their vault.
• Sub-intermediate Keys: Encryption keys generated for specific features operated by the enclave, such as activity logs.

3.5.3 Secure Channels

Figure: Protocol to build an encrypted channel using Libsodium

Secure channels are how clients securely communicate with enclaves. They are end-to-end encrypted channels between a client and enclaves, preventing a man-in-the-middle from eavesdropping on those communications.

The client generates ephemeral key pairs and requests the enclave to create a secure channel. Upon being requested to mount a channel, the enclave generates its own key pairs and embeds the public key within a cryptographically signed attestation.

Nitro attestations are a set of properties of the runtime environment issuing the attestation, signed by the Nitro Hypervisor underlying the workload. Those properties are sealed as measurements called Platform Configuration Registers (PCRs)—basically hashes—into the attestation, to be verified by clients when checking the attestation.

Once the Dashlane application has verified the attestation and agreed on the PCRs within, the client is guaranteed that the public key embedded into the attestation is the one of a genuine enclave. Dashlane applications base their verification on two PCRs:

• PCR3: A contiguous measurement of the IAM role assigned to the parent instance; ensures that the attestation process succeeds only when the parent instance has the correct IAM role. 
• PCR8: A measure of the signing certificate specified for the enclave image file; ensures that the attestation process succeeds only when the enclave was booted from an enclave image file signed by a specific certificate.

Therefore, the client can proceed with the key exchange and generate the cryptographic material to encrypt communication to the secure enclave.

Secure channels are based on the Libsodium library. As stated in the documentation of the library, the following primitives are used:

• X25519 and BLAKE2B-512 for the key exchange
• XChaCha20-Poly1305 for secretstreams