En junio de 2026, tres acontecimientos reavivaron el debate sobre las garantías reales de los gestores «zero-knowledge»: un estudio académico de ETH Zurich y Aalto University cartografía 25 ataques explotables si el servidor está comprometido, una filtración en LastPass transita por un CRM de terceros, y un investigador de DEF CON 33 demuestra el secuestro del autofill mediante clickjacking. He aquí el impacto concreto de estos tres acontecimientos en la arquitectura de ARDNTECH, sin retórica de marketing.
Publicado el 23 de junio de 2026 por ARDNTECH EI · Análisis interno a partir de las divulgaciones públicas
Un robo de tokens OAuth en Klue (herramienta de inteligencia comercial integrada en Salesforce) permitió acceder a los datos de contacto de clientes de LastPass. Los cofres cifrados no quedaron expuestos. El riesgo real es el phishing dirigido a partir de una lista de contactos robada en un subcontratista periférico, no el compromiso del núcleo criptográfico.
Enseñanza : el zero-knowledge protege los cofres, no los metadatos en poder de terceros.
Matteo Scarlata y sus coautores (difundidos por Ars Technica) cartografían 25 ataques que muestran que las garantías «zero-knowledge» de Bitwarden, Dashlane y LastPass se degradan si el servidor está comprometido y si ciertas funcionalidades opt-in están activas: recuperación de cuenta, compartición mediante distribución de claves públicas, retrocompatibilidad criptográfica (downgrade KDF).
Enseñanza : un ZK formalmente correcto debe resistir el escenario de un servidor comprometido, no solo el de un administrador honesto.
Marek Tóth demuestra que el autofill de 11 gestores puede activarse mediante un overlay invisible. Un solo clic en un falso banner de cookies basta para rellenar los campos de una página controlada por el atacante. La superficie afectada es la lógica de inyección DOM de la extensión, no el cofre del servidor.
Enseñanza : la extensión de navegador es una superficie de ataque distinta del servidor, que debe endurecerse de forma independiente.
El estudio apunta a tres familias de funcionalidades que, en un servidor comprometido, debilitan las garantías ZK. He aquí su correspondencia en la arquitectura de ARDNTECH.
| Vector del estudio | Arquitectura de ARDNTECH | Veredicto |
|---|---|---|
|
Recuperación de cuenta
Copia de la clave del cofre almacenada del lado del servidor, utilizable si el servidor está comprometido |
El wrap se produce del lado del cliente (Argon2id) a partir de un código de recuperación que solo el usuario posee. El servidor almacena wraps opacos: no puede volver a derivar la clave. Consumo con scrub inmediato. | Sano |
|
Downgrade criptográfico
Forzar a un cliente a usar un algoritmo más débil durante el wrap de recuperación |
Bloqueado del lado del servidor: un componente de inspección analiza la armadura real (SKESK v6, S2K Argon2id, AEAD presente, costes mínimos). Un cliente manipulado que haga downgrade es rechazado y obligado a una reactivación. | Neutralizado |
|
Sustitución de clave pública al compartir
El servidor sirve su propia clave en lugar de la del destinatario |
El servidor expone la clave pública + la huella del destinatario. Una corrección de junio de 2026 (repo de extensiones) cubre la verificación del lado del cliente. Punto residual: asegurarse de que un cambio de clave de un contacto conocido active una alerta explícita. | En verificación |
|
Claves de recuperación de administrador (tipo LastPass)
Un administrador de grupo puede volver a cifrar el cofre de un usuario del lado del servidor |
ARDNTECH no dispone de un mecanismo «break-glass admin» del lado del servidor que vuelva a cifrar la clave del cofre de un usuario hacia una clave de administrador. La compartición de equipo pasa únicamente por la clave pública del equipo y su huella. | Sano por diseño |
Síntesis : un servidor de ARDNTECH comprometido no permite descifrar los wraps de recuperación: son opacos, derivados del lado del cliente a partir de un secreto que el servidor no posee, y el downgrade KDF se rechaza en el registro. Son precisamente los escenarios explotados en otros gestores por el estudio ETH/Aalto. Aquí están cerrados mediante decisiones arquitectónicas documentadas en el modelo de amenazas.
La investigación de Tóth apunta a la lógica de inyección DOM de las extensiones. El autofill y el autologin son las superficies afectadas. El cofre del servidor no está en cuestión: es la extensión que rellena los campos la que puede ser engañada. Los puntos siguientes están en proceso de auditoría en la extensión de ARDNTECH.
visibility:hidden, tamaño próximo a cero o elemento recubierto (hit-testing del punto de clic).window.top === window.self o del mismo origen.z-index controlado, reverificación de visibilidad en el momento del clic.Un núcleo criptográfico sano puede ser eludido por la pila SaaS periférica. Los cofres de LastPass no se movieron, pero una lista de contactos fue robada en un integrador CRM de terceros.
Los subcontratistas actuales de ARDNTECH (Scaleway, Brevo, Stancer, HIBP, Bugsink) están delimitados en el registro publicado en la página Confianza. El zero-knowledge protege los cofres, no una lista de contactos en un CRM de terceros no inventariado.
Rotación de los tokens de integraciones de terceros, scopes mínimos, revocación inmediata en caso de incidente. Los accesos a los sistemas periféricos no deben permitir reconstituir una cartografía de los clientes.
Zero-knowledge verificable, alojado en Francia, código fuente AGPLv3. La beta privada es accesible previo registro.