Guilgo Blog

Un estudio de ETH Zurich y la Università della Svizzera italiana ha identificado 25 vectores de ataque de recuperación de contraseñas en gestores de contraseñas en la nube muy utilizados. El trabajo analiza las promesas de cifrado de conocimiento cero (ZKE) de Bitwarden, LastPass y Dashlane —que suman más de 60 millones de usuarios y unas 125.000 empresas— y demuestra que, bajo el supuesto de un servidor malicioso o comprometido, varias de esas garantías pueden romperse. En este post se resume el estudio, se explica cómo funcionan los ataques y se plantea una forma de mitigar riesgos mediante despliegue self-hosted en Docker, sin asumir ningún caso de uso concreto.

Resumen del estudio: 25 ataques en gestores de contraseñas en la nube

La investigación, recogida en The Hacker News, parte de un modelo de amenaza en el que el servidor que almacena los cofres (vaults) es malicioso o está comprometido. El objetivo es comprobar si se cumplen las garantías de cifrado de conocimiento cero (ZKE): que el proveedor no pueda acceder a los secretos del usuario. ZKE no es lo mismo que el cifrado de extremo a extremo (E2EE): E2EE protege los datos en tránsito; ZKE se centra en que los datos almacenados solo sean accesibles para quien tiene la clave.

Los autores —Matteo Scarlata, Giovanni Torrisi, Matilda Backendal y Kenneth G. Paterson— encuentran 12 ataques distintos contra Bitwarden, 7 contra LastPass y 6 contra Dashlane, con severidad que va desde violaciones de integridad hasta el compromiso completo de todos los cofres de una organización. No hay constancia de que ninguno de estos vectores se haya explotado en la práctica.

1Password también aparece en el estudio como vulnerable a ataques de cifrado a nivel de ítem y de compartición; el fabricante los considera limitaciones arquitectónicas ya documentadas y no vectores nuevos. Los gestores afectados han implementado o están implementando contramedidas (Bitwarden, LastPass y Dashlane han parcheado o endurecido varios puntos; Dashlane, por ejemplo, eliminó cifrado legacy en la extensión 6.2544.1 de noviembre de 2025).

Qué significa esto para el usuario: contexto del modelo de amenaza

Es importante no sacar conclusiones alarmistas del estudio. El modelo de amenaza asume que el atacante controla el servidor (o lo ha comprometido completamente). Eso significa que:

• No es un ataque remoto desde internet. Un atacante cualquiera no puede explotar estos vectores contra tu cofre sin antes haber comprometido la infraestructura del proveedor o del servidor self-hosted.
• No es explotable por un usuario malintencionado que simplemente conozca tu email o tu cuenta; requiere acceso privilegiado al backend.
• No invalida el uso de gestores de contraseñas en la nube. Usar Bitwarden, LastPass o Dashlane sigue siendo mucho más seguro que reutilizar contraseñas o guardarlas en texto plano. El estudio cuestiona las garantías de ZKE bajo un escenario extremo, no la utilidad general de estas herramientas.

Dicho de otro modo: si usas Bitwarden cloud, no estás “vendido”. Estás expuesto a estos vectores solo si alguien toma el control del servidor de Bitwarden, y los fabricantes ya están parcheando los puntos débiles que el estudio señala.

Cómo funcionan los ataques: las cuatro categorías

El estudio agrupa los ataques en cuatro categorías. Entenderlas ayuda a valorar el riesgo y a elegir mitigaciones.

Key Escrow (recuperación de cuenta)

En Bitwarden y LastPass existe un mecanismo de recuperación de cuenta cuando se pierde la contraseña maestra. Eso implica que algún material (clave, secret) queda bajo control del servidor o puede derivarse con su colaboración.

Un servidor malicioso podría explotar fallos en el diseño de ese “key escrow”: capturar o manipular lo que el cliente envía durante la recuperación y, en determinadas condiciones, derivar la clave maestra o desbloquear el cofre. El ataque compromete la confidencialidad que se espera del ZKE.

Cifrado a nivel de ítem y metadatos

Cada ítem (contraseña, nota segura) se cifra, pero a menudo por partes: título, usuario, URL, contraseña, etc. son campos separados, y los metadatos (tipo de ítem, nombres de campos) pueden ir sin cifrar o sin estar ligados criptográficamente al contenido.

Un servidor malicioso puede:

• Violar integridad: modificar metadatos para que el cliente interprete mal un ítem o mezcle campos.
• Filtrar información: inferir datos a partir de longitudes de ciphertext, tipos de ítem, etc.
• Hacer “field swapping”: intercambiar campos entre ítems al no existir un binding criptográfico por campo.
• Forzar un KDF downgrade: ofrecer al cliente una versión antigua del protocolo que use una función de derivación de clave más débil (menos iteraciones, algoritmo peor), de modo que un atacante pueda probar contraseñas maestras con menos coste.

En la práctica, el servidor modifica lo que almacena o lo que envía al cliente; el cliente (app Bitwarden, etc.) descifra y podría mostrar datos alterados o derivar la clave con parámetros más débiles.

Compartición entre usuarios

Al compartir un ítem con otro usuario, el servidor debe almacenar algo que permita al destinatario descifrarlo. Ese flujo puede exponer material que el servidor ve o puede manipular, rompiendo confidencialidad o integridad del cofre de quien comparte o de quien recibe.

Compatibilidad con código legacy (downgrade)

Si el servidor sigue aceptando clientes antiguos que usan cifrado o KDF más débiles, un atacante que controle el servidor puede forzar o inducir el uso de esa versión antigua. El cliente negocia o usa protocolo legacy; el atacante captura el tráfico o el ciphertext y ataca offline la derivación de clave o el cifrado con mucho menos esfuerzo que contra la versión actual.

Self-hosted en Docker: no es “más seguro”, es un cambio de trust boundary

Conviene ser claro: desplegar un gestor de contraseñas en Docker no lo hace automáticamente más seguro. Lo que cambia es en quién confías. En la nube confías en el proveedor (Bitwarden Inc., LastPass, etc.); en self-hosted confías en tu propia infraestructura: tu servidor, tu red, tus backups, tu mantenimiento. Si tu infraestructura no está a la altura, el riesgo puede ser incluso mayor que en la nube.

Dicho esto, el modelo de amenaza del estudio (“servidor malicioso”) se traduce en self-hosted a: ¿qué pasa si alguien compromete mi host o mi contenedor? Y aquí Docker añade sus propios riesgos si no se configura bien: un contenedor corriendo como root, el daemon de Docker expuesto a la red sin autenticación (tcp://0.0.0.0:2375), o un volumen montado con permisos excesivos convierten tu self-hosted en el “Bitwarden cloud comprometido” de tu propia historia. El atacante ni siquiera necesita los 25 vectores del paper: con acceso al daemon o al volumen ya tiene la base de datos.

Cómo se ve un despliegue razonable

Para visualizar qué significa “trust boundary” en la práctica, un esquema mínimo de arquitectura sería:

Internet
  │
  ▼
Reverse proxy (nginx/Caddy) ── TLS termination, certificado válido
  │
  ▼
Red interna Docker (bridge aislado)
  │
  ▼
Contenedor Vaultwarden ── usuario no-root, sin privilegios extra
  │
  ▼
Volumen cifrado (LUKS, ZFS encrypted, etc.) ── db.sqlite3 + attachments
  │
  ▼
Backup cifrado y off-site

Cada capa es una frontera de confianza: si el reverse proxy cae, el atacante llega al contenedor; si el contenedor cae, llega al volumen. Cifrar el volumen y los backups es la última línea antes de que los datos del vault queden expuestos.

Mantener el contenedor y la imagen actualizadas

Actualizar con frecuencia la imagen Docker del servidor (por ejemplo, Vaultwarden u otra implementación compatible con el protocolo Bitwarden) permite incorporar parches de seguridad y, en su caso, la retirada de protocolos o cifrados legacy que facilitan ataques de downgrade.

• Usar una imagen con tag fijo o digest para reproducibilidad, pero planificar actualizaciones periódicas.
• Revisar release notes y avisos de seguridad del proyecto antes de cada despliegue.

Reducir superficie: recuperación de cuenta y compartición

• Key Escrow: Si la instalación self-hosted ofrece recuperación de cuenta (key escrow), valorar desactivarla si no es necesaria, para eliminar ese vector.
• Compartición: Si no se usa la función de compartir ítems entre usuarios, el riesgo asociado a esa categoría no aplica; en entornos donde sí se use, conviene asegurarse de que el servidor y los clientes están actualizados.

Aislamiento y red

• Ejecutar el contenedor con la menor cantidad de privilegios necesaria y, si es posible, red aislada (por ejemplo, red interna de Docker) exponiendo solo el puerto estrictamente necesario (por ejemplo, tras un reverse proxy con TLS).
• Proteger el tráfico cliente-servidor con HTTPS (TLS) para evitar que un atacante en la red actúe como intermediario y fuerce downgrades o manipule respuestas.

Cliente actualizado

Muchas de las mejoras frente a estos ataques se implementan en el cliente (app oficial Bitwarden, etc.). Mantener el cliente actualizado es tan importante como actualizar el servidor en Docker: así se aprovechan las contramedidas (por ejemplo, rechazo de protocolos legacy o validación de integridad) que los fabricantes han ido desplegando tras el estudio.

Las amenazas reales en self-hosted: más allá del estudio

En la práctica, el riesgo principal de un despliegue self-hosted no viene del escenario académico del paper (servidor malicioso de fábrica), sino de errores operativos mucho más comunes:

• Backups sin cifrar. Si la base de datos del gestor (por ejemplo, el db.sqlite3 de Vaultwarden) se respalda en texto plano o en un volumen accesible, un atacante que llegue al host tiene el vault entero sin necesidad de explotar ninguno de los 25 ataques del estudio.
• Base de datos expuesta o robada. Un volumen Docker mal configurado, permisos laxos en el sistema de ficheros o un snapshot de VM sin proteger pueden dejar la base de datos al alcance de quien no debería.
• Reverse proxy mal configurado. Si el proxy que expone el servicio no fuerza TLS, permite protocolos antiguos (TLS 1.0/1.1) o no valida correctamente los certificados, se abre la puerta a ataques de intermediario que son más sencillos y probables que los del paper.

Endurecer estos tres puntos (backups cifrados, permisos estrictos sobre la base de datos y reverse proxy con TLS moderno bien configurado) aporta más seguridad real que cualquier mitigación derivada del estudio.

Conclusión

El estudio de ETH Zurich y USI demuestra que, bajo el supuesto de servidor malicioso, varios gestores de contraseñas en la nube son vulnerables a ataques que van desde violaciones de integridad hasta el compromiso de cofres. Pero el modelo de amenaza exige control total del servidor: no es un ataque que cualquiera pueda lanzar desde internet, y no invalida el uso de estos gestores.

En un despliegue self-hosted en Docker, el “servidor” eres tú. Docker no es una mitigación en sí mismo; es un cambio de trust boundary. La seguridad real viene de mantener actualizados servidor y cliente, reducir funcionalidades innecesarias (key escrow, compartición), aislar la red con TLS y, sobre todo, cuidar lo básico: backups cifrados, base de datos protegida y reverse proxy bien configurado. Esos puntos operativos son, en la práctica, más determinantes que los escenarios del paper.

Qué hacer hoy: checklist rápida

Si usas un gestor en la nube (Bitwarden, LastPass, Dashlane):

• Actualiza la app/extensión del cliente a la última versión disponible.
• Activa 2FA en tu cuenta del gestor si no lo tienes ya.
• Revisa si tienes habilitada la recuperación de cuenta (key escrow) y valora si la necesitas.
• No entres en pánico: el estudio requiere servidor comprometido, no es un ataque remoto.

Si usas un despliegue self-hosted (Vaultwarden, etc.) en Docker:

• Actualiza la imagen del contenedor y revisa las release notes.
• Comprueba que el contenedor NO corre como root y que el daemon de Docker no está expuesto.
• Verifica que el reverse proxy fuerza TLS 1.2+ con un certificado válido.
• Asegúrate de que los backups de la base de datos están cifrados y fuera del host.

Referencias

• Artículo original: Study Uncovers 25 Password Recovery Attacks in Major Cloud Password Managers — The Hacker News (16 feb 2026).
• Investigación: ETH Zurich y Università della Svizzera italiana; autores: Matteo Scarlata, Giovanni Torrisi, Matilda Backendal, Kenneth G. Paterson.