La Directiva NIS2 es el marco actualizado de ciberseguridad de la Unión Europea, diseñado para mejorar la resiliencia cibernética en todos los sectores críticos. Basándose en
Los gestores de contraseñas están entre las herramientas de seguridad más útiles disponibles, ya que ofrecen la creación segura de contraseñas y el almacenamiento cifrado de credenciales. Sin embargo, los atacantes están comenzando a apuntar a los administradores de contraseñas al aprovechar el flujo de registro de dispositivos, que es el proceso que se utiliza para verificar y aprobar un nuevo dispositivo antes de que pueda acceder a la bóveda de un usuario. Al aplicar fuerza bruta a las contraseñas de un solo uso (OTP) que protegen este paso, los atacantes pueden registrar dispositivos no autorizados y descargar copias de bóvedas cifradas.
Esto es lo que le sucedió a Dashlane en mayo de 2026: los atacantes forzaron por fuerza bruta los códigos de seis dígitos utilizados para registrar nuevos dispositivos, agregaron dispositivos no autorizados a menos de 20 cuentas y descargaron copias de las bóvedas de esos usuarios. El cifrado en sí nunca se rompió, pero la vulnerabilidad estaba en cómo se aprobaban los nuevos dispositivos. Los ataques de fuerza bruta que tienen como objetivo el registro de dispositivos del administrador de contraseñas son una ciberamenaza creciente, pero son ineficaces contra la arquitectura de confianza cero y conocimiento cero de Keeper, la cual garantiza que conocer una contraseña nunca es suficiente para registrar un dispositivo y acceder a una bóveda.
Cómo funcionan los ataques de fuerza bruta en el registro de dispositivos
Cuando agrega un nuevo dispositivo a un administrador de contraseñas, el proveedor del servicio debe verificar que el dispositivo es suyo antes de otorgarle acceso a su bóveda. Este paso de confirmación en el flujo de registro del dispositivo es el objetivo de estos ataques de fuerza bruta. Para comprender por qué los administradores de contraseñas como Dashlane eran vulnerables a este ataque, mientras que otros como Keeper® no lo son, a continuación se explica cómo suelen funcionar estos ataques:
- Se emite un código: tras agregar un nuevo dispositivo a una cuenta, el servicio debe verificar la identidad del usuario, generalmente enviando un OTP de seis dígitos por correo electrónico o generándolo con una aplicación de autenticación. Introducir este código demuestra que la persona que registra el dispositivo es el propietario legítimo de la cuenta.
- El endpoint se inunda: dado que un OTP de seis dígitos solo tiene 1 millón de combinaciones posibles, un atacante puede inundar un endpoint de la API de registro de dispositivos con solicitudes automáticas. Si el endpoint no aplica límites de tasa, ventanas de caducidad de código o bloqueos por intento, el atacante puede adivinar rápidamente los posibles valores hasta identificar el código válido.
- Se adivina un código válido: tras suficientes intentos contra un endpoint débilmente protegido, el atacante eventualmente adivinará un código correcto. Dado que ese código es prueba de la identidad del usuario, el dispositivo del atacante es aceptado como legítimo.
- El dispositivo está registrado: el proveedor de servicios autoriza el nuevo dispositivo y sincroniza la bóveda encriptada del usuario con él. Aunque los datos de la bóveda permanecen encriptados, el atacante ahora cuenta con una copia de los datos encriptados y puede intentar descifrarlos sin conexión de manera indefinida.
Este proceso no es hipotético; es la forma en que se desarrolló el ataque a Dashlane. Por lo tanto, asegurar el flujo de registro del dispositivo es tan importante como proteger las bóvedas.
Por qué el registro no autorizado de dispositivos crea riesgo
El registro no autorizado de dispositivos supone serios riesgos de seguridad porque, una vez que un nuevo dispositivo está registrado en una cuenta de gestor de contraseñas, puede acceder a la bóveda del usuario y aparecer como un usuario legítimo y autenticado. El atacante no necesita eludir, debilitar ni romper el cifrado de la bóveda para llevar a cabo este tipo de ataque de fuerza bruta. Lo único que necesitan es que el proveedor de servicios confíe en su dispositivo, lo que permitirá que los datos cifrados de la bóveda se sincronicen directamente con el hardware que controlan.
Las implicaciones de que un atacante posea una copia de la bóveda encriptada de un usuario son a largo plazo, ya que el atacante puede intentar descifrarla fuera de línea a su propio ritmo durante el tiempo que sea necesario para acceder a ella. Si bien el cifrado robusto de la bóveda hace que, estadísticamente, sea poco probable que esto funcione, la probabilidad depende en gran medida de un factor que el usuario puede controlar: la solidez de su contraseña maestra. Una contraseña maestra larga, compleja y singular puede evitar que vulneren una bóveda exfiltrada, pero una contraseña maestra débil o reutilizada tiene muchas más probabilidades de ser descifrada con el tiempo suficiente. Asegurar el flujo de registro del dispositivo es esencial para que la protección de la bóveda de un usuario no dependa completamente de la solidez de su contraseña maestra.
Keeper ayuda a prevenir ataques de registro de dispositivos por fuerza bruta: cómo lo hace
Las personas que usan Keeper no serían víctimas del mismo tipo de ataque de fuerza bruta que afectó a Dashlane porque Keeper garantiza que simplemente conocer la contraseña de un usuario o forzar con éxito una OTP no es suficiente para registrar un nuevo dispositivo o acceder a una bóveda.
Aprobación de dispositivos
Con Keeper, cada nuevo dispositivo debe ser aprobado explícitamente antes de que pueda acceder a una bóveda. Esta aprobación es un paso separado e intencional, y no algo que ocurre inmediatamente después de que se ingresa un código. En el caso de usuarios individuales, la aprobación proviene del propietario de la cuenta utilizando un dispositivo ya de confianza; en el caso de empresas, un administrador puede aprobar nuevos dispositivos en nombre de usuarios legítimos. En este tipo de ataque, adivinar un OTP válido es suficiente para completar el registro del dispositivo, pero con Keeper no existe un único endpoint de API cuyo código pueda ser vulnerado por fuerza bruta para finalizar el proceso.
Autenticación Multifactor (MFA)
Keeper soporta una variedad de métodos MFA, o autenticación de dos factores (2FA), como claves de seguridad hardware FIDO2/WebAuthn, biometría, aplicaciones de autenticación y SMS. Sin embargo, no todos estos métodos son igualmente resistentes a los ataques de fuerza bruta. Los códigos enviados por correo electrónico o SMS son los más vulnerables, ya que pueden adivinarse o interceptarse en tránsito. Las aplicaciones de autenticación ofrecen una mayor protección porque el código se genera localmente en el dispositivo del usuario, pero aún dependen de códigos cortos basados en el tiempo y por tanto dependen de limitaciones de velocidad y otros controles para evitar intentos de fuerza bruta. Las llaves de seguridad de hardware proporcionan la protección más fuerte porque se basan en la autenticación criptográfica de desafío-respuesta en vez de un código corto. Dado que no existe un valor predecible que un atacante pueda enviar repetidamente a un endpoint de API, los ataques de fuerza bruta dirigidos al registro de dispositivos se vuelven ineficaces.
Seguridad de confianza cero
Keeper se basa en un modelo de seguridad de confianza cero, lo que significa que cada solicitud de acceso debe ser verificada independientemente de la ubicación de la red o del historial previo de autenticación. Con Keeper, a un dispositivo no se le otorga una confianza persistente e implícita simplemente porque ya esté registrado o verificado; cada solicitud se evalúa de forma independiente. Este modelo de seguridad implica que, incluso si un atacante lograra de alguna manera registrar un dispositivo, esa oportunidad en particular no le otorgaría acceso continuo. Bajo un marco de confianza cero, no existe ningún mecanismo por el cual un atacante pueda explotar el registro de dispositivos para obtener acceso indefinido.
Módulo de informes avanzados y alertas (ARAM)
El módulo de informes avanzados y alertas (ARAM) de Keeper ofrece a los administradores visión sobre comportamientos sospechosos en su entorno, como anomalías de autenticación e intentos de registro de dispositivos. Los intentos de verificación que ocurren dentro de un período corto de tiempo o un volumen alto de intentos fallidos de registro de dispositivos son exactamente los tipos de eventos que ARAM puede mostrar. Tener plena visibilidad de la actividad inusual permite a los administradores actuar con rapidez, en vez de permitir que un comportamiento sospechoso pase desapercibido hasta que se haya registrado un dispositivo no autorizado.
Para obtener más información sobre cómo se compara la arquitectura de aprobación de dispositivos, autenticación y cifrado de Keeper con la de Dashlane, visite nuestra Página de comparación de Keeper vs Dashlane.
Por qué es importante la arquitectura de conocimiento cero de Keeper
Los controles de acceso de Keeper están diseñados para impedir que un atacante registre un dispositivo, pero otra capa de protección refuerza aún más la seguridad: una arquitectura de conocimiento cero. En la práctica, el conocimiento cero significa que todo lo almacenado en la bóveda de un usuario está encriptado de extremo a extremo en todo momento, por lo que ni siquiera Keeper puede descifrarlo. Dado que las claves de cifrado se generan en el dispositivo del usuario, los datos también se cifran y descifran de forma local, lo que garantiza que la bóveda permanezca completamente bajo el control del usuario. Incluso si un atacante obtuviera de alguna manera una copia de la bóveda cifrada de un usuario, se enfrentaría a un desafío casi imposible, ya que las claves de cifrado necesarias para desbloquear una bóveda de Keeper no existen en la infraestructura de Keeper.
Proteja sus datos ante ataques de fuerza bruta con Keeper
El incidente de seguridad de Dashlane demuestra que el cifrado sólido de la bóveda por sí solo no es suficiente. A medida que los atacantes cambian su enfoque de descifrar bóvedas encriptadas a explotar los flujos de trabajo que otorgan acceso, es esencial comprender cómo prevenir ataques de fuerza bruta y asegurar los procesos de registro y autenticación de dispositivos. Un gestor de contraseñas debe proteger tanto las bóvedas de usuario como el flujo que gestiona quién puede acceder a ellas.
La brecha de LastPass de 2022 tuvo un resultado similar, pero a través de una ruta diferente: los atacantes comprometieron la infraestructura de la compañía y robaron copias de bóvedas encriptadas, pero desde entonces los investigadores de seguridad han rastreado el robo hasta bóvedas débilmente protegidas. Tanto los incidentes de Dashlane como los de LastPass muestran que, una vez que un atacante obtiene acceso a la bóveda encriptada de los usuarios, pueden atacar de forma indefinida, lo que subraya la importancia de usar un administrador de contraseñas seguro para proteger sus datos.
Keeper está diseñado para protegerse contra este tipo de ataques mediante la aprobación de dispositivos, asegurando que un código adivinado no pueda registrar un nuevo dispositivo por sí solo; múltiples métodos de autenticación multifactor (MFA); y un modelo de seguridad de confianza cero, que garantiza que ningún dispositivo sea implícitamente confiable. Estas protecciones operan dentro de una arquitectura de conocimiento cero que mantiene las claves de cifrado bajo el control del usuario.
Inicie una prueba gratuita de Keeper para ver cómo su seguridad en capas garantiza que los datos de su bóveda estén cifrados con claves que solo usted controla.