Internal note: Notify of changes

6.1 Passkeys

Dashlane’s passkey implementation brings phishing-resistant, passwordless authentication into its zero-knowledge architecture. Unlike traditional password managers that store passkeys alongside regular credentials, Dashlane uses a confidential computing model to ensure that cryptographic key material is protected from device compromise.

• Phishing-resistant by design: Passkey authentication is based on origin-bound credentials; traditional phishing attacks are ineffective.
• Confidential computing protection: AWS Nitro Enclaves isolate cryptographic passkey operations, and the private key never leaves the secure cloud environment during creation and usage.
• Standard-based: Passkeys are built on top of the W3C WebAuthn and FIDO CTAP standards and supported by the industry through the FIDO Alliance.

Each passkey consists of a public/private key pair generated using the WebAuthn standard. Dashlane does not store the private key on the user’s device, it remains encrypted on the server.

Upon a request to generate a new passkey for a domain, the client sends a generation request to the AWS Nitro Enclave through a secure channel (as explained in 3.5.3 Secure Channels). The enclave generates both the passkey public/private key-pair and a symmetric encryption key. The private key is encrypted within the enclave using this symmetric key (AES-256-CBC + HMAC-SHA256). The symmetric key is then returned to the client to be stored in the user’s locally encrypted vault, while the encrypted private key is stored in a classic datastore.

When a user attempts to log in, the client forwards the WebAuthn challenge, the clientDataJSON (containing the origin and challenge), and the symmetric encryption key to the enclave. The enclave uses the symmetric key to decrypt the passkey's private key. It then validates that the origin within the clientDataJSON matches the intended domain before signing the data. The resulting signature is forwarded back to the client, which completes the authentication as if the passkey were stored locally.

6.2 Passwordless Login

Dashlane’s passwordless login eliminates the Master Password while maintaining the same cryptographic strength and zero‑knowledge guarantees that define its security model. Instead of a user‑defined password, each account is protected by a Machine‑Generated Master Password (MachineGeneratedMP), a high‑entropy secret generated and stored securely on the user’s device.

At account creation, Dashlane generates the MachineGeneratedMP locally and uses it to derive the user’s AES‑256 vault encryption key. The MachineGeneratedMP never leaves the user’s device in plaintext and is never stored on Dashlane’s servers. On mobile and desktop, this key is protected by the platform’s hardware security module (HSM), such as the Apple Secure Enclave or Android Keystore, and accessed only when the user authenticates with a biometric factor (Face ID, fingerprint) or PIN.

When a passwordless user adds a new device, they use an existing, logged-in device to complete the setup. This secured process is described in section 4.1.3.

6.3 FIDO2 Security Keys

Dashlane supports FIDO2-compliant security keys—such as YubiKeys and other hardware authenticators—to provide the highest level of phishing-resistant authentication for both enterprise and individual users. These hardware devices integrate with Dashlane’s zero-knowledge architecture to deliver cryptographic, hardware-backed authentication as a primary factor for accessing the Dashlane application.

Passkeys stored on FIDO2 security keys extend the inherent phishing-resistant properties of FIDO2 by enabling the derivation of a credential-specific symmetric key through the WebAuthn PRF and CTAP hmac-secret extensions. Dashlane leverages these standards-based extensions to derive encryption keys that protect and encrypt the user’s vault, ensuring that sensitive data remains accessible only to the authenticated user.

When a FIDO2 security key is used in this configuration, users are required to configure a local device PIN on the security key. This enforces a strong, multi-factor authentication model that combines something the user has (the hardware key) with something the user knows (the PIN), further safeguarding access to Dashlane credentials.

Through native support for FIDO2 hardware security keys, Dashlane delivers robust, standards-based, phishing-resistant authentication and encryption, strengthening the overall security posture of the Dashlane vault.

6.4 Preventing Phishing Attacks Against Dashlane

Dashlane employs multiple layers of defense to protect its users and infrastructure from phishing attacks, ensuring that neither Dashlane accounts nor its authentication workflows can be exploited.

6.4.1 Domain-Level and Application-Level Phishing Protection

Dashlane maintains continuous monitoring and deny-list of malicious domains that impersonate Dashlane or its services. This protection operates at multiple levels:

• Application-level protection: The Dashlane extension and mobile apps automatically prevent autofill on suspicious or impersonated domains.
• DNS and infrastructure controls: Dashlane enforces strict domain verification, HSTS preloading, and DMARC/SPF/DKIM policies to prevent spoofed emails or subdomain takeovers.
• Threat intelligence and takedown: Dashlane collaborates with external threat intelligence partners to identify and remove phishing domains targeting Dashlane users.

6.4.2 In-Browser Phishing Prevention

Within the Dashlane client, phishing protection mechanisms ensure users are never prompted for sensitive information outside trusted contexts. Autofill operates under strict same-origin and content security policies, meaning credentials can only be filled into verified sites that match their stored domains. In addition, the AI Phishing Detection system continuously analyzes URLs and SSL certificates to prevent autofill on suspicious pages.

6.4.3 Continuous Monitoring and Response

Dashlane’s Security team operates a dedicated monitoring and incident response process to detect phishing attempts against both users and Dashlane’s brand. Alerts from domain monitoring, email authentication failures, and reported user incidents are triaged to ensure rapid mitigation.