How Keeper Protects Against Brute Force Attacks on Password Manager Device Registration

Password managers are among the most helpful security tools available, offering strong password generation and encrypted credential storage. However, attackers are beginning to target password managers by exploiting the device registration flow, which is the process used to verify and approve a new device before it can access a user’s vault. By brute-forcing the One-Time Passwords (OTPs) that protect this step, attackers can register unauthorized devices and download copies of encrypted vaults.

This is what happened to Dashlane in May 2026: Attackers brute-forced the six-digit codes used to register new devices, adding unauthorized devices to fewer than 20 accounts and downloading copies of those users’ vaults. The encryption itself was never broken, but the vulnerability was in how new devices were approved. Brute force attacks targeting password manager device registration are a growing cyber threat, but they are ineffective against Keeper’s zero-trust, zero-knowledge architecture, which ensures that knowing a password is never enough to register a device and access a vault.

How brute force attacks on device registration work

When you add a new device to a password manager, the service provider must verify that the device is yours before granting you access to your vault. This confirmation step in the device registration flow is what these brute force attacks target. To understand why password managers like Dashlane were vulnerable to this attack while others like Keeper^® aren’t, here is how the attacks typically work:

1. A code is issued: After adding a new device to an account, the service must verify the user’s identity, typically by sending a six-digit OTP via email or by generating it with an authenticator app. Entering this code proves the person registering the device is the legitimate account owner.
2. The endpoint gets flooded: Since a six-digit OTP only has 1 million possible combinations, an attacker can flood a device registration API endpoint with automated requests. If the endpoint doesn’t enforce rate limits, code expiry windows or per-attempt lockouts, the attacker can rapidly guess possible values until they identify the valid code.
3. A valid code is guessed: After enough attempts against a weakly protected endpoint, the attacker will eventually guess a correct code. Since that code is proof of the user’s identity, the attacker’s device is accepted as legitimate.
4. The device is registered: The service provider authorizes the new device and syncs the user’s encrypted vault to it. Although the vault data remains encrypted, the attacker now has a copy of the encrypted data and can attempt to decrypt it offline indefinitely.

This process isn’t hypothetical; it’s how the Dashlane attack unfolded, which is why securing the device registration flow matters as much as protecting vaults.

Why unauthorized device registration creates risk

Unauthorized device registration introduces serious security risks because once a new device is registered to a password manager account, it can access the user’s vault and appear as an authenticated, legitimate user. The attacker doesn’t need to bypass, weaken or break the vault’s encryption at all to carry out this type of brute force attack. All they need is for the service provider to trust their device, allowing the encrypted vault data to be synced directly to hardware under their control.

The implications of an attacker possessing a copy of a user’s encrypted vault are long term since the attacker can attempt to crack it offline at their own pace for as long as it takes to gain access. Although strong vault encryption makes this statistically unlikely to succeed, the likelihood of success heavily depends on something the user can control: the strength of their master password. A long, complex and unique master password can prevent an exfiltrated vault from being cracked, but a weak or reused master password has a much higher chance of being cracked given enough time. Securing the device registration flow is essential so that a user’s vault protection does not depend entirely on the strength of their master password.

How Keeper helps prevent brute force device registration attacks

People using Keeper would not fall victim to the same kind of brute force attack that affected Dashlane because Keeper ensures that simply knowing a user’s password or successfully brute-forcing an OTP is not enough to register a new device or access a vault.

Device approval

With Keeper, each new device must be explicitly approved before it can access a vault. This approval is a separate, intentional step rather than something that occurs as soon as a code is entered. For individual users, approval comes from the account owner using an already trusted device; for enterprises, an administrator can approve new devices on behalf of legitimate users. In this type of attack, guessing a valid OTP is enough to complete device registration, but with Keeper, there is no single API endpoint whose code can be brute-forced to finish the process.

Multi-Factor Authentication (MFA)

Keeper supports a variety of MFA, or Two-Factor Authentication (2FA), methods, including FIDO2/WebAuthn hardware security keys, biometrics, authenticator apps and SMS. Not all of these methods are equally resistant to brute force attacks, though. Codes sent via email or SMS are the most vulnerable, as they can be guessed or intercepted in transit. Authenticator apps provide stronger protection because the code is generated locally on the user’s device, but they still rely on short, time-based codes and therefore depend on rate-limiting and other controls to prevent brute force attempts. Hardware security keys provide the strongest protection because they rely on cryptographic challenge-response authentication instead of a short code. Because there is no predictable value for an attacker to repeatedly submit to an API endpoint, brute force attacks targeting device registration become ineffective.

Zero-trust security

Keeper is built on a zero-trust security model, meaning every access request must be verified regardless of network location or prior authentication history. With Keeper, a device isn’t granted persistent, implicit trust simply because it was already registered or verified; each request is evaluated independently. This security model means that even if an attacker were somehow able to register a device, that single success wouldn’t grant ongoing access. Under a zero-trust framework, there is no mechanism by which an attacker can exploit device registration to gain indefinite access.

Advanced Reporting & Alerts Module (ARAM)

Keeper’s Advanced Reporting & Alerts Module (ARAM) gives administrators visibility into suspicious behavior across their environment, including authentication anomalies and device registration attempts. Verification attempts occurring within a short timeframe or a high volume of failed device registration attempts are exactly the types of events ARAM can surface. Having full visibility into unusual activity allows administrators to act quickly, rather than letting suspicious behavior go unnoticed until after an unauthorized device has been registered.

To learn more about how Keeper’s device approval, authentication and encryption architecture compares to Dashlane’s, visit our Keeper vs Dashlane comparison page.

Why Keeper’s zero-knowledge architecture is important

Keeper’s access controls are designed to stop an attacker from ever registering a device, but another layer of protection further strengthens security: a zero-knowledge architecture. In practice, zero knowledge means that everything stored in a user’s vault is end-to-end encrypted at all times, so not even Keeper can decrypt it. Because encryption keys are generated on the user’s device, data is encrypted and decrypted locally as well, ensuring the vault stays entirely under the user’s control. Even if an attacker somehow obtained a copy of a user’s encrypted vault, the attacker would face a nearly impossible challenge since the encryption keys needed to unlock a Keeper Vault don’t exist on Keeper’s infrastructure.

Protect your data from brute force attacks with Keeper

Dashlane’s security incident proves that strong vault encryption alone is not sufficient. As attackers shift their focus from cracking encrypted vaults toward exploiting the workflows that grant access, understanding how to prevent brute force attacks and securing device registration and authentication processes is essential. A password manager must protect both user vaults and the flow that manages who can access them.

LastPass’s 2022 breach had a similar outcome, but via a different path: Attackers compromised the company’s infrastructure and stole copies of encrypted vaults, but security researchers have since traced the theft to weakly protected vaults. Both the Dashlane and LastPass incidents show that once an attacker gains access to a user’s encrypted vault, it can be attacked indefinitely, underscoring the importance of using a secure password manager to protect your data.

Keeper is built to defend against these types of attacks through device approval, ensuring a guessed code can’t register a new device on its own; multiple MFA methods; and a zero-trust security model, which ensures no device is implicitly trusted. These protections operate within a zero-knowledge architecture that keeps encryption keys under the user’s control.

Start a free trial of Keeper to see how its layered security ensures your vault data is encrypted under keys only you control.