Internal note: Notify of changes

4.1 Authentication Flows and Vault Encryption Lifecycle

4.1.1 Registration

The initial registration for a user follows the flow described in the following figure.

As a reminder, neither the User Master Password nor the Machine-Generated Master Password are ever used to perform server authentication, and the only keys stored on our servers are the User Device Keys.

Figure: Authentication Flow during registration

Upon registration, the server generates a User Device Key and sends it back to the client application. The User Device Key consists of two parts:

• The Device Access Key: A public part acting as a key identifier (8 random bytes hexa encoded string)
• The Device Secret Key: A secret part (32 random bytes hexa encoded string)

When requesting the server, the application produces a signature with HMAC-SHA256 over the body and parts of the request headers and with the Device Secret Key as the signing key. The signature is set in the headers request along with the Device Access Key. This way, the Device Secret Key isn’t exposed to the network after the registration workflow.

4.1.2 Adding a New Device for Master Password-based Users

When a user adds an additional device, Dashlane needs to ensure that the person adding the device is indeed the legitimate owner of the account. This is to provide additional protection in the event UserMP has been compromised and an attacker who does not have access to the user’s already-enabled device is trying to access the account from another device.

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) that is sent to the user to the email address used to create the Dashlane account initially.

Figure: Authentication when adding a new device

Upon validation of the OTP by the server after the user enters it into the application, the device is provided with a User Device Key to authenticate to the server (cf 4.1.1 Registration).

Once the device is authenticated to our server, the device can download the user’s vault in its encrypted form (cf 3.2 Encryption Model: Secrets and Protections). Then, the user can decrypt their vault by providing their Master Password.

This workflow enforces a multi-factor way of accessing the plaintext version of a user’s data.

4.1.3 Adding a New Device for Passwordless Users

When a passwordless user adds a new device, they use an existing, logged-in device to complete the setup. Depending on the trusted device type, the setup can be finalized either through a QR code scan (proximity method) or a security challenge (remote method). In both cases, the goal is to securely transfer the Machine-Generated Master Password (MachineGeneratedMP) from an already trusted device to a new one.

This key exchange is based on Elliptic Curve Cryptography (Curve25519), ensuring strong security and protection against interception.

Figure: Adding a new device for passwordless users

Proximity Transfer with QR Code Scan

If the user has a logged-in mobile device, a QR code can be used to authorize the new device. When the user enters their email on the untrusted device, it generates an X25519 key pair and displays its public key as a QR code. The trusted device scans this code, completing the key exchange. Both devices then derive the same shared secret, which becomes a cryptographic key used to encrypt and transmit the MachineGeneratedMP. Once received, the new device decrypts the vault locally and becomes authorized.

Exchange via Server with Visual Verification

If a user cannot perform a QR scan (for example, if they lack a camera-enabled trusted device), the exchange occurs through Dashlane’s servers using a Short Authenticated String (SAS) verification. This process authenticates the key exchange and ensures integrity:

• From the shared secret, Dashlane derives a key used to select five random words from the EFF large word list.
• Both devices display these words; if the lists match, the exchange is authentic. The user is asked to confirm by entering a missing word on the trusted device.
• A Public Key Commitment mechanism adds further protection. The untrusted device first sends a hash of its X25519 public key before revealing the key itself, preventing an attacker from manipulating the exchange in real time.

Upon successful verification, the MachineGeneratedMP is securely transmitted to the new device, allowing it to decrypt the vault locally. This design provides strong protection against man-in-the-middle attacks while maintaining a seamless user experience.

4.1.4 Adding a New Device With a Security Key (FIDO2)

When the account is protected with a security key, registering a new device is based on a WebAuthn flow with the passkey stored in the Security Key. Upon validation of the WebAuthn flow, the device is provided with a User Device Key.

Then, the device can download the encrypted vault from the server. The decryption is based on the PRF extension of the WebAuthn standard, letting the Security Key issue a symmetric key from the passkey to decrypt the MachineGeneratedMP of the account (downloaded along with the encrypted vault).

4.2 Multi-Factor Authentication (MFA)

For Master Password-based accounts, Dashlane can strengthen account protection through multi-factor authentication (MFA), which adds an additional layer of security beyond the Master Password. MFA ensures that even if one factor is compromised, unauthorized access to the vault remains highly unlikely.

By combining multiple authentication factors with local encryption, Dashlane ensures that access to user vaults and administrative functions remains secure, even in the event of stolen credentials or compromised devices.

Users can enable MFA at any time from the Dashlane web extension or mobile app. Dashlane offers two levels of MFA.

4.2.1 MFA for New Device Setup

When connecting a new device, instead of sending a one-time token via email, Dashlane can prompt for a one-time code generated by the linked 2FA authenticator app. After the code is validated, a new Device Key is securely registered for that device, maintaining zero-knowledge architectures.

4.2.2 MFA at Each Login

Users can link their Dashlane account to an authenticator app (for example, Google Authenticator or Microsoft Authenticator). Each login requires both the Master Password and a one-time verification code.

When activated, both the locally stored data and the synchronized vault data are re-encrypted with a new symmetric AES-256 key derived from the combination of the user’s primary credential (Master Password) and a User Secondary Key generated on Dashlane’s servers: The output of the Argon password-hashing function is XOR-ed with the high-entropy key generated on Dashlane’s servers.

The User Secondary Key is transmitted to the client only after successful MFA verification, ensuring that both factors are required to decrypt the vault.

4.2.3 Enterprise MFA Controls

For Dashlane business accounts, administrators can enforce MFA through policy settings in the Admin Console.

4.3 Account Recovery

Dashlane provides secure, zero-knowledge account recovery options to ensure that users can regain access to their vaults without compromising encryption or privacy. Different complementary methods are available:

• Account Recovery Key (ARK) and Biometric Recovery on Mobile for all users
• Admin-Assisted Account Recovery for business users

4.3.1 Account Recovery Key (ARK)

The Account Recovery Key (ARK) provides a self-service fallback for individual users and supports zero-knowledge design principles. The ARK is a unique, single-use, 28-character alphanumeric key generated by Dashlane’s password generator during setup.

• During configuration, the ARK is confirmed and saved by the user. A derivative key encrypts the Master Password locally using AES-256 and stores only the encrypted value on Dashlane servers.
• The ARK can be disabled at any time from the user’s security settings, invalidating the existing key.
• In the event the user forgets their Master Password or loses access to all devices, they can initiate recovery by verifying their identity via email code or 2FA token. After successful verification, the server releases the encrypted Master Password, which is decrypted locally using the ARK. The user is then prompted to create a new Master Password.

Once the process is complete, the old ARK becomes invalid. A new key must be generated and confirmed in the user’s security settings. The ARK is also automatically disabled when the Master Password is changed or a user switches from Master Password login to SSO, passwordless, or a security key.

These recovery mechanisms combine usability and security, empowering users to regain access independently while maintaining Dashlane’s zero-knowledge guarantees.

4.3.2 Biometric Recovery on Mobile

Biometric Recovery provides a device-specific recovery mechanism for mobile users, strictly adhering to zero-knowledge design principles. This feature leverages hardware-backed security capabilities to allow Master Password replacement without server intervention. The implementation varies between platforms to leverage native security features while maintaining equivalent security guarantees.

On Android, when the user enables Biometric Recovery, a copy of the Local Key, a 64-byte randomly generated symmetric key that encrypts the vault data, is encrypted and stored locally. The encryption uses a cryptographic key generated within the Android Keystore System, which is backed by the device's Trusted Execution Environment (TEE) or Secure Element. Access to this key requires successful biometric authentication (fingerprint or face recognition).

On iOS, a copy of the Master Password is encrypted and stored in the iOS Keychain with biometric access control, leveraging the Secure Enclave when available. The Master Password is used to decrypt the Local Key. In both implementations, cryptographic secrets never reach Dashlane servers during setup or recovery.

Recovery Process

When a user forgets their Master Password, they initiate recovery on the device where the feature was enabled:

• The user authenticates via biometric prompt (fingerprint, face recognition, Touch ID, or Face ID). Upon successful authentication, the secure storage releases the cryptographic secret:
  • Android: The Local Key is decrypted into memory.
  • iOS: The Master Password is retrieved and used to decrypt the Local Key.
• The user creates a new Master Password, which re-encrypts the Local Key.
• The updated structure synchronizes to Dashlane servers, enabling access from other devices with the new Master Password.

Throughout this process, raw cryptographic secrets never leave the device, preserving zero-knowledge architecture.

Security Safeguards

Biometric Recovery can be disabled at any time, immediately purging encrypted material from secure storage. Both platforms protect against unauthorized access when device biometrics change:

• Android: The operating system automatically invalidates Keystore keys when new biometric templates are enrolled (for example, a new fingerprint is added), immediately disabling recovery.
• iOS: The application monitors biometric enrollment changes via the Local Authentication framework's domain state hash. When changes are detected (for example, new Face ID enrollment), the feature automatically deactivates and removes the stored Master Password.

In both cases, users must explicitly reenable and reauthenticate to restore functionality after biometric changes, ensuring new individuals cannot gain unauthorized vault access.

4.3.3 Admin-Assisted Account Recovery for Business

Admin-assisted account recovery allows Dashlane business users who log in with a Master Password to securely reset it while preserving zero-knowledge guarantees. Dashlane’s patented recovery process ensures that Master Passwords are never stored on servers or transmitted in any form. The zero-knowledge architecture ensures that account recovery can only be initiated from a device on which the user has previously logged in.

When admin-assisted recovery is enabled and the user first logs in, the user's Local Key is encrypted with a locally-created User Recovery Key. The resulting Encrypted Local Key is stored in the device's local storage.

The User Recovery Key is then encrypted with a Server Recovery Key (known only by the server and the user's client devices), producing the Server Protected Recovery Key. The client then encrypts this Server Protected Recovery Key with each admin's Public Key to generate the Server and Admin Protected Recovery Keys. If the team has N admins, there will be N of these keys.

Only the Server and Admin Protected Recovery Keys are sent to the server. Crucially, the User Recovery Key and the Server Protected Recovery Key (the intermediate key) never leave the user device. Once the server has received the encrypted keys, admin-assisted account recovery is fully enabled for the user.

When the user initiates a recovery flow, they must first verify their identity and define a new Master Password. Upon definition of the new Master Password, a public/private key pair is created on the user device. The private key is encrypted with the new Master Password and stored locally, while the public key is sent to the server along with the recovery request.

The admin then verifies the request, acting as a trusted third party to confirm the action. Once approved, the admin's Private Key (associated with the public key used at activation) is used to decrypt its Server and Admin Protected Recovery Keys. The result, the Server Protected Recovery Key, is then encrypted locally with the user's new Public Key to create a Server and User Protected Recovery Key, which is returned to the server. This process ensures that the Server Protected Recovery Key is never sent to the server in an unencrypted form, preserving Dashlane's zero-knowledge guarantee over the User Recovery Key.

After the admin's approval and cryptographic operation, the user can authenticate with the new Master Password. This Master Password is used to retrieve the user's Private Key, which then decrypts the Server and User Protected Recovery Key. The result is the Server Protected Recovery Key, which is then decrypted using the Server Recovery Key to yield the original User Recovery Key. This final key is used to decrypt the Encrypted Local Key, recovering the Local Key. This step allows the extension to access the user's local vault data. Finally, the vault is re-encrypted with the new Master Password and synced with the server.

After recovery, all other devices must be reregistered with Dashlane to maintain secure synchronization. Admin-assisted recovery can be enabled or disabled by administrators from the Admin Console.

Privacy note: Because the admin serves as a trusted verifier, if they have access to both the user’s device and account email, they could theoretically trigger a recovery and access the vault. Organizations should restrict such privileges to trusted personnel only.

4.4 Secure Sharing

Dashlane enables users to share credentials and Secure Notes, maintaining its zero-knowledge architecture throughout the process. Shared data is always encrypted end-to-end, ensuring that neither Dashlane nor any third party can access the content.

• Zero-knowledge architecture: Dashlane servers handle only encrypted data; the decryption keys never leave user-controlled environments.
• Granular access control: Users can grant different levels of rights when sharing credentials.
• Traceability: For business users, every sharing action is logged in Activity Logs for enterprise visibility and compliance.

4.4.1 Sharing Mechanism

Dashlane’s sharing system relies on asymmetric encryption. Upon account creation, each user generates a unique pair of RSA 2048-bit public and private keys:

• The public key is stored on Dashlane’s servers and used to encrypt shared data for the intended recipient.
• The private key remains encrypted in the user’s vault and is never shared or transmitted.

When a user (Alice) shares an item with another user (Bob):

1. Dashlane retrieves Bob’s public key.
2. Alice generates a random 256-bit AES key (the ObjectKey) to encrypt the item.
3. The ObjectKey is encrypted using Bob’s public key and sent to Bob through Dashlane’s servers.
4. Bob decrypts the ObjectKey with his private key, then decrypts the shared item locally.

4.4.2 Group and Collection Sharing

Dashlane also supports sharing with groups or collections of items, using an additional layer of symmetric encryption:

• A GroupKey (AES-256) is generated for each group or collection.
• Each member’s public key encrypts the GroupKey, ensuring that only authorized users can access shared credentials.
• The GroupKey’s corresponding RSA private key is used to sign and manage shared items within that group, providing auditability and integrity.

4.4.3 Link-based Sharing

Dashlane enables users to share credentials with anyone, including recipients who do not have a Dashlane account or the Dashlane extension installed. This feature preserves Dashlane's zero-knowledge architecture by ensuring encryption keys are never transmitted to Dashlane servers.

Overview

Link-based sharing allows users to generate a time-limited, access-controlled URL that displays credential details (username, password, and TOTP codes if configured) on a secure landing page. The link automatically expires based on configurable conditions: time elapsed or number of views. Once any expiration condition is met, the link becomes permanently invalid.

Encryption and Key Management

When a user initiates link-based sharing:

• The Dashlane application generates K1, a 64-byte cryptographic key split into two 32-byte components: one for AES-256-CBC encryption and one for HMAC-SHA256 authentication.
• The credential is encrypted locally using this key pair before being transmitted to Dashlane's servers.
• Dashlane's server generates a unique itemUuid and stores the encrypted payload on AWS S3.
• The application constructs a sharing URL in the format: https://share.dashlane.com/{itemUuid}#{K1}

For instance:

https://share.dashlane.com/0c90af73-d077-43ca-9fc7-32a74cfa79cc#6f642db043b3bf775294772516785686ba93371a5cd592b600e1b857f4aff17d1268358012f8b523a4553abe20a71306122ff8366e4bcba5c9fc80415904b31a 

where :

The URL uses a fragment identifier (#) to separate the itemUuid from K1. By design, URL fragments are never transmitted to servers, ensuring that Dashlane never sees the decryption key, even in transit.

This preserves zero-knowledge guarantees throughout the sharing process.

Link Access and Decryption

When a recipient opens the link:

• The landing page extracts the itemUuid from the URL path and K1 from the fragment.
• A Cloudflare Turnstile challenge is completed to prevent automated enumeration attacks.
• The landing page requests the encrypted payload from Dashlane's servers using only the itemUuid.
• Dashlane's server validates expiration conditions (time and remaining views) and decrements the view counter atomically.
• If valid, the encrypted payload is returned to the landing page.
• The landing page decrypts the credential locally using K1 and displays the contents to the recipient.

Expiration and Automatic Cleanup

Link-based shares enforce strict expiration controls to minimize exposure:

• Time-based expiration: Links expire after 24h.
• View-based expiration: Links can be only accessed one time.

First-condition-met: the link expires as soon as any single condition is satisfied.

Server-side, Dashlane periodically scans for expired items and:

• Deletes the encrypted payload and shared item entry from storage
• Generates an audit log entry recording the expiration event

When a user's account is deleted, all link-based shares created by that user are immediately destroyed, regardless of their configured expiration. The encrypted payloads are removed from S3, and corresponding audit logs are generated.

Enterprise Controls

Link-based sharing is governed by team settings in the Admin Console:

• Sharing functionality dependency: Link-based sharing requires the "Secure sharing for logins, Secure Notes and Secrets" policy to be enabled.
• External sharing dependency: Link-based sharing requires the "Allow sharing outside company" policy to be enabled.
• Link sharing policy: Administrators can enable or disable link-based sharing for their organization.

These controls ensure that organizations can restrict link-based sharing based on their security and compliance requirements.

Auditability

For enterprise customers, link-based sharing generates Activity Log entries for full traceability:

• Link created: Records the user who created the link, the item identifier, expiration settings, and originating IP address.
• Link accessed: Records each access attempt, including the recipient's IP address and timestamp.
• Link expired: Records when a link expires, whether due to time, view limits, or manual deletion.

These logs are available to administrators through the Admin Console and support compliance and incident response workflows.

4.5 Password Health Score

The Password Health score helps users and organizations measure and improve the overall strength of their stored credentials. Each password in the vault is evaluated based on key criteria—strength, reuse, and exposure in known breaches—to produce an overall score.

• Reused or weak passwords reduce the score and generate actionable alerts.
• Compromised passwords detected via Dark Web Monitoring are flagged for immediate update.

Admins and individual users can access detailed reports through their Security Dashboards, which include trend tracking and prioritized remediation recommendations. By quantifying credential hygiene, the Password Health score provides a clear metric for improving enterprise password security and reducing exposure to credential-based attacks.

4.6 Password Generator

Dashlane’s built-in Password Generator helps users create strong, unique credentials and passphrases that balance complexity with memorability. Users can customize generation settings to meet personal or enterprise security policies:

• Password options: Choose length (4–40 characters), include or exclude letters, digits, symbols, or similar characters, and ensure compliance with site-specific rules.
• Passphrase mode: Generate easy-to-remember yet highly secure phrases composed of random words, separated by spaces or special characters. Passphrases typically offer higher entropy while maintaining usability. Length can be defined between 4 and 8 words.
• Automatic integration: The generator is integrated into the autofill experience and the web extension, enabling quick credential generation and replacement during sign-up or password updates.

By promoting the use of high-entropy passwords and customizable passphrases, Dashlane’s Password Generator significantly reduces password reuse and strengthens overall credential hygiene across individual and enterprise accounts.

4.7 Dark Web Monitoring

4.7.1 Dark Web Monitoring for Vault Credentials

This feature alerts Dashlane users if their monitored email addresses appear in a known data breach. To determine if an email is compromised, Dashlane checks it against databases compiled from verified third-party breach sources.

Upon subscription to Dark Web Monitoring alerts, the user will receive an email with a link. The link activates the monitoring. The user will be redirected to a page on the website (www.dashlane.com) with a summary of the known data leaks, if there are any, for the given email. The summary includes the following information: affected company/domain, date of the breach, data type affected (credit cards, emails, passwords, identity, etc).

Whenever new breaches occur, the user will be notified in the Dashlane application if one of the monitored emails appeared in the breach.

Users can monitor up to five different email addresses.

4.7.2 Dark Web Monitoring for Master Password

This feature alerts Dashlane users if their Master Password appears in a known data breach. To determine if a password is compromised, Dashlane checks it against databases compiled from verified third‑party breach sources.

All breach data collected through partner APIs is hashed using the Argon2d v1.3 function before storage on Dashlane servers. When a user enters their Master Password in the mobile or web app, the client applies the Argon2d algorithm with a unique salt specific to this feature (different from the salt used for vault encryption) to produce a 32‑byte hash:

To preserve zero‑knowledge architecture, Dashlane uses a k‑anonymity model: The full hash never leaves the user’s device. Only the first three bytes of the hash are sent to Dashlane’s servers to check for potential matches in breach datasets. If matches are found, the server returns a list of candidate hashes for local comparison.

The Dashlane application then compares the full hash locally; if it matches one from the breach list, the user is immediately alerted that their Master Password may have been compromised and should be changed. This ensures that no plaintext passwords or full hashes ever leave the device, maintaining privacy even during monitoring.

This privacy‑preserving process enables Dashlane to provide real‑time breach alerts and maintain its zero‑knowledge promise, ensuring that no one, including Dashlane, can ever access or reconstruct a user’s Master Password.

Figure: Dark Web Monitoring for Master Password

4.7.3 Dark Web Insights for Businesses

Dark Web Insights expands Dark Web Monitoring to cover the entire organization, including employees without Dashlane accounts. It continuously scans the dark web for employee email addresses associated with verified company domains, enabling detection of domain-wide breaches and exposed organizational data.

When an admin verifies a company domain for Dark Web Insights, all corresponding work email addresses are automatically enrolled and monitored. Employees who are already Dashlane plan members continue to manage their individual exposure through Dark Web Monitoring and receive alerts when their data appears in a breach.

Dashlane compares verified domains against breach datasets sourced from trusted third-party providers. Any credentials matching the organization’s domains are aggregated in the Dark Web Insights dashboard, with results also available via CSV export. Reports include the breached services, breach dates, affected email addresses, and the types of exposed data (such as usernames, passwords, or payment information).

To drive better security hygiene, admins can invite some or all non-plan employees identified in Dark Web Insights to create a Dashlane account, helping extend protection and remediation across the workforce.

4.7.4 Credential Risk Detection

Credential Risk Detection is a business feature that applies the same monitoring as Dark Web Monitoring for Master Password, but on credentials autofilled, copy-pasted, or manually typed by employees on company-managed browsers where Dashlane is deployed. See 5.7.1 Credential Risk Detection section for more details.

4.8 Import and Export

Dashlane supports secure import and export of credentials to help individuals and organizations onboard efficiently or transition their data when needed.

4.8.1 CSV Import

Credentials can be imported from other password managers or browsers using CSV files, a widely supported industry format. During import, credentials are processed locally on the user’s device and encrypted immediately according to Dashlane’s zero-knowledge architecture before being stored or synchronized. This ensures that plaintext credentials are never exposed to Dashlane servers.

4.8.2 Export

For export, users can choose between a standard CSV format or Dashlane’s proprietary encrypted export. CSV exports provide interoperability with third-party tools but contain credentials in plaintext and should be handled with care.

Dashlane’s proprietary export preserves end-to-end encryption, ensuring that credentials remain protected and can only be decrypted by an authorized Dashlane client. These options allow consumers and organizations to balance interoperability, security, and operational needs while maintaining control over sensitive credential data.

4.8.3 Credential Exchange and Portability

Dashlane supports FIDO Credential Exchange to ensure credential portability (including passkeys) across platforms and devices without sacrificing security. This protocol enables secure import and export using a short-lived asymmetric key exchange validated through QR code proximity or visual verification.

All operations occur using elliptic-curve cryptography (Curve25519) and ephemeral session keys. The private key never leaves the secure hardware enclave of the original device. The exchanged payload is encrypted and signed before being relayed through Dashlane’s servers, which act solely as a transport layer and have no visibility into the underlying data.

Credential Exchange is currently only supported on iOS, with Android support coming in early 2026.