Gestores de contraseñas: claves para elegir el más seguro

Se determina por su arquitectura criptográfica, el tratamiento de la clave maestra, los mecanismos de autenticación, la capacidad de auditoría y el control que conserva el usuario sobre sus datos.

Un gestor puede sincronizar credenciales entre varios dispositivos y, al mismo tiempo, mantener una exposición limitada para el proveedor. También puede ofrecer cifrado avanzado y seguir siendo vulnerable si la clave maestra es débil, si el dispositivo está infectado o si el servicio carece de controles verificables. Por eso, los criterios de elección deben analizarse como un sistema, no como una lista de prestaciones aisladas.

La arquitectura de conocimiento cero es el punto de partida

La arquitectura de conocimiento cero establece una separación técnica entre el usuario y el proveedor. La empresa almacena una bóveda cifrada, pero no debería poder acceder a la clave maestra ni a los datos descifrados que contiene.

El modelo exige que el cifrado se realice antes de que la información salga del dispositivo. El servidor recibe datos ilegibles sin la clave adecuada. La contraseña maestra no se almacena en texto claro y, en un diseño correctamente implementado, tampoco se envía al proveedor para validar el acceso.

Este modelo reduce el impacto de una intrusión en los servidores. Si un atacante obtiene una copia de la base de datos cifrada, no recibe directamente las contraseñas guardadas. Sin embargo, la arquitectura de conocimiento cero no convierte una bóveda en indestructible. La resistencia real depende de varios componentes:

• La clave maestra debe tener suficiente longitud y no reutilizarse en otros servicios.
• La función de derivación debe dificultar los ataques automatizados contra contraseñas.
• El cifrado debe ejecutarse de extremo a extremo, no únicamente durante la conexión con el servidor.
• El proceso de recuperación de cuenta no debe crear una vía alternativa para eludir la protección principal.
• Las aplicaciones cliente deben proteger la clave mientras la bóveda está abierta.
• El proveedor debe documentar qué metadatos conserva y durante cuánto tiempo.

La expresión conocimiento cero se utiliza con frecuencia de forma imprecisa. No basta con indicar que los datos están cifrados. Un servicio puede cifrar la comunicación mediante TLS y mantener el contenido descifrado en sus propios sistemas. Ese mecanismo protege el transporte, pero no equivale a una arquitectura en la que el proveedor no puede leer la bóveda.

El cifrado protege la información. La arquitectura determina quién puede descifrarla.

AES-256, XChaCha20 y derivación de claves

Los gestores de contraseñas seguros suelen utilizar algoritmos simétricos como AES-256 o XChaCha20. Ambos pertenecen a familias criptográficas consolidadas, pero el nombre del algoritmo no permite evaluar por sí solo la seguridad completa del producto.

El análisis debe incluir la forma en que el gestor transforma la clave maestra en una clave criptográfica. Para esa función se emplean mecanismos de derivación como PBKDF2-SHA256 o Argon2. Su objetivo es aumentar el coste computacional de cada intento de descifrado y dificultar los ataques de fuerza bruta sobre una bóveda robada.

La diferencia operativa es relevante. Una contraseña maestra sencilla sigue siendo una contraseña sencilla después de pasar por un algoritmo robusto. La derivación puede elevar el coste de cada intento, pero no sustituye la entropía de la clave original.

Al evaluar la documentación técnica, conviene localizar estos elementos:

1. Algoritmo de cifrado simétrico. Debe estar identificado con precisión. Las expresiones genéricas como cifrado militar o seguridad de nivel bancario no describen una implementación.

2. Función de derivación de claves. El proveedor debe indicar si utiliza PBKDF2-SHA256, Argon2 u otro mecanismo y, cuando sea posible, sus parámetros de configuración.

3. Cifrado de extremo a extremo. La bóveda debe cifrarse en el dispositivo antes de la sincronización.

4. Gestión de claves. La política debe explicar qué ocurre con la clave maestra, los dispositivos autorizados y los procesos de recuperación.

5. Separación de datos. Las contraseñas, notas seguras, documentos y metadatos no tienen por qué tratarse de la misma manera. La documentación debe distinguirlos.

Un producto que solo publicita AES-256 no ha demostrado todavía una arquitectura segura. Faltan la derivación, la gestión de sesiones, la protección de memoria y los controles de acceso.

Auditorías y código abierto: evidencias distintas

La seguridad declarada por un proveedor no equivale a la seguridad verificada por terceros. Las auditorías independientes permiten examinar el diseño, el código o determinados componentes del servicio. Su valor depende del alcance, la fecha, la firma auditora y la publicación de los resultados.

Una auditoría de seguridad realizada por una firma especializada, como Cure53, puede detectar vulnerabilidades de diseño, fallos de implementación o problemas en la lógica de autenticación. No significa que el gestor quede libre de vulnerabilidades para siempre. La auditoría analiza una versión, un alcance y un periodo concretos.

Hay que distinguir cuatro preguntas:

• ¿Se auditó la aplicación cliente, el servidor o ambos?
• ¿El informe cubre el sistema criptográfico o solo la interfaz?
• ¿La revisión corresponde a la versión actual?
• ¿El proveedor publica los problemas encontrados y las medidas correctoras?

La fecha importa porque los gestores cambian. Una actualización puede introducir un componente nuevo, modificar el sistema de sincronización o alterar el proceso de recuperación. Una auditoría antigua conserva valor histórico, pero no valida automáticamente la versión instalada hoy.

Qué aporta el código abierto

El código abierto permite que investigadores independientes revisen el software. Esta posibilidad mejora la transparencia. También facilita la comparación entre el comportamiento documentado y la implementación real.

No obstante, código abierto no significa código auditado de forma permanente. Un repositorio público puede contener miles de líneas que apenas han sido revisadas. El usuario debe comprobar si existen revisiones externas, actividad de mantenimiento, gestión pública de incidencias y documentación sobre las versiones distribuidas.

El código abierto aporta más valor cuando se combina con:

• Reproducibilidad de las compilaciones.
• Historial público de cambios.
• Informes de vulnerabilidades y respuesta documentada.
• Revisión independiente de los componentes criptográficos.
• Compatibilidad verificable entre el código publicado y la aplicación descargada.

Un producto cerrado puede tener una arquitectura sólida y auditorías independientes. Un producto abierto puede ofrecer una transparencia mayor, pero no queda exento de errores. La comparación correcta no es código abierto frente a código cerrado como criterio absoluto. Es evidencia verificable frente a afirmaciones no comprobables.

Autenticación multifactor: la bóveda no debe depender de una sola credencial

La autenticación multifactor añade una segunda barrera después de la contraseña maestra o de la credencial principal. Su función es impedir que el robo de un único elemento baste para abrir la cuenta.

Los gestores actuales pueden admitir varias modalidades:

• Aplicaciones de códigos temporales basados en tiempo, conocidas como TOTP.
• Datos biométricos protegidos por el sistema operativo.
• Llaves físicas de seguridad compatibles con FIDO2, como YubiKey.
• Passkeys o claves de acceso vinculadas al dispositivo y a la criptografía de clave pública.
• Códigos de recuperación para situaciones de pérdida del segundo factor.

No todas las modalidades ofrecen la misma resistencia frente a ataques. Los códigos TOTP protegen frente al uso directo de una contraseña robada, pero pueden quedar expuestos en procesos de phishing o mediante técnicas de ingeniería social. Las llaves físicas y las passkeys reducen la dependencia de códigos que el usuario debe copiar o introducir manualmente.

La disponibilidad de MFA no es suficiente. Hay que revisar cómo se activa, qué ocurre si se pierde el dispositivo y si el método de recuperación permite desactivar el segundo factor sin una verificación equivalente.

Comparativa de métodos de segundo factor

La mejor configuración depende del riesgo. Para una cuenta con contraseñas de administración, información corporativa o acceso a sistemas sensibles, una llave física o una passkey puede ofrecer un control superior al de un código temporal. Para un usuario que necesita compatibilidad entre dispositivos antiguos, TOTP puede ser una solución práctica, siempre que se protejan los códigos de recuperación.

El autorrelleno también es una función de seguridad

El autorrelleno no solo reduce el tiempo necesario para iniciar sesión. Bien implementado, puede limitar la exposición frente al phishing. El gestor reconoce el dominio asociado a una credencial y evita introducir los datos en una dirección web que no coincide con la registrada.

Este control depende de la coincidencia exacta del dominio y de la forma en que la aplicación interpreta subdominios, redirecciones y páginas integradas. El usuario no debería copiar manualmente una contraseña desde la bóveda hacia cualquier ventana que la solicite. Esa acción elimina parte de la protección contextual del autorrelleno.

Hay varios errores habituales:

• Guardar una credencial con una dirección demasiado genérica.
• Aceptar el autorrelleno en un dominio parecido al legítimo.
• Ignorar una alerta de coincidencia parcial.
• Copiar la contraseña al portapapeles y dejarla expuesta.
• Utilizar el mismo registro para varios dominios sin comprobar el servicio concreto.

El gestor debe diferenciar entre una dirección legítima y una variante creada para imitarla. La seguridad no depende únicamente de la interfaz. También depende de si el sistema comprueba el dominio antes de entregar la credencial.

En móviles, este análisis incorpora otro elemento: el sistema de autorrelleno del sistema operativo. El usuario debe saber qué aplicación tiene permiso para leer y completar credenciales. Un gestor dedicado puede proporcionar controles más específicos, pero la aplicación seguirá estando condicionada por los permisos del dispositivo.

Almacenamiento local o sincronización en la nube

La elección entre un gestor local y uno sincronizado en la nube afecta a la disponibilidad, la recuperación y la superficie de ataque. No existe una respuesta universal. El modelo adecuado depende del número de dispositivos, la necesidad de acceso remoto y la capacidad técnica para mantener copias y actualizaciones.

Cuándo tiene sentido un modelo local

Un gestor local puede ser adecuado cuando el usuario necesita limitar la dependencia de terceros y puede gestionar copias de seguridad cifradas. También puede encajar en entornos sin conectividad permanente o con requisitos específicos de custodia.

El coste es operativo. La bóveda debe estar disponible en los dispositivos autorizados, las copias deben mantenerse actualizadas y la recuperación debe probarse antes de que ocurra un incidente. Una copia de seguridad que nunca se ha restaurado no constituye un procedimiento validado.

El autoalojamiento añade control sobre la infraestructura, pero también responsabilidades. El administrador debe aplicar actualizaciones, proteger el servidor, controlar los accesos y monitorizar los registros. No es una forma automática de mejorar la seguridad. Traslada parte del riesgo desde el proveedor hacia la organización que gestiona el sistema.

Cuándo encaja la nube

La nube resulta útil cuando se necesita sincronización continua, acceso desde varios dispositivos y recuperación centralizada. En este caso, la arquitectura de conocimiento cero adquiere una importancia decisiva. El proveedor debe poder sincronizar una bóveda cifrada sin acceder al contenido.

El análisis no termina en el cifrado. También hay que revisar:

• Ubicación y jurisdicción de los datos.
• Política de conservación de metadatos.
• Registro de dispositivos y sesiones activas.
• Notificación de incidentes de seguridad.
• Exportación de la bóveda en un formato utilizable.
• Eliminación de la cuenta y de las copias asociadas.
• Cumplimiento de obligaciones de privacidad, incluido el RGPD cuando resulte aplicable.

La sincronización aporta disponibilidad. También crea más puntos de autenticación. Cada dispositivo autorizado puede convertirse en una vía de acceso si no está protegido con bloqueo, cifrado y actualizaciones.

Privacidad: no toda la información de una bóveda es igual

La protección de datos personales no se limita al contenido de las contraseñas. El proveedor puede tratar direcciones de correo, identificadores de dispositivo, horarios de acceso, direcciones IP, registros de errores y datos de uso. Estos metadatos pueden revelar patrones aunque la bóveda permanezca cifrada.

Un gestor orientado a la privacidad debe explicar qué recopila, con qué finalidad y durante cuánto tiempo. La política debe diferenciar entre datos necesarios para prestar el servicio y datos utilizados para análisis, publicidad o desarrollo comercial.

El RGPD aporta obligaciones sobre información, base jurídica, derechos de las personas y medidas de seguridad. No certifica por sí solo que un producto sea técnicamente superior. El cumplimiento normativo y la solidez criptográfica son capas distintas.

Para comparar el tratamiento de datos, el usuario debe buscar respuestas concretas:

• ¿Se registra la dirección IP en cada acceso?
• ¿Se conserva el historial de dispositivos?
• ¿Se analizan los títulos de las entradas de la bóveda?
• ¿La telemetría puede desactivarse?
• ¿Se comparte información con proveedores externos?
• ¿Se puede solicitar la eliminación completa de la cuenta?
• ¿La exportación incluye todos los datos en un formato abierto?

La privacidad también depende del cliente. Instalar la aplicación desde una fuente no oficial, conceder permisos innecesarios o usar extensiones desconocidas puede invalidar parte de las garantías del servicio central.

La elección del gestor debe incluir un procedimiento de verificación

Antes de contratar o migrar una bóveda, conviene auditar la información disponible y comprobar el funcionamiento real de la aplicación. El proceso puede organizarse en cinco fases.

1. Identificar la arquitectura

Localiza la documentación sobre cifrado de extremo a extremo, conocimiento cero, derivación de claves y recuperación de cuenta. Si el proveedor utiliza términos generales sin explicar el flujo de las claves, la información es insuficiente.

No es necesario que el usuario implemente criptografía. Sí debe poder identificar quién genera la clave, dónde se utiliza y qué ocurre cuando se sincroniza la bóveda.

2. Verificar la autenticación

Comprueba si el gestor permite TOTP, llaves FIDO2, passkeys o biometría. Revisa si el segundo factor se exige también para nuevos dispositivos y para cambios de configuración.

La cuenta debe tener un procedimiento de recuperación documentado. Los códigos de emergencia no deben guardarse en la misma bóveda a la que permiten acceder. Tampoco deben permanecer en una captura de pantalla almacenada en el móvil principal.

3. Revisar auditorías y mantenimiento

Consulta si existen auditorías independientes, qué componentes cubren y a qué versión corresponden. Revisa el historial de actualizaciones y la respuesta del proveedor ante vulnerabilidades.

La ausencia de una auditoría pública no demuestra que el producto sea inseguro. Sí reduce la evidencia disponible para evaluar sus afirmaciones.

4. Probar el autorrelleno

Crea registros diferenciados para servicios con dominios similares. Comprueba si la aplicación identifica el dominio correcto y si evita completar credenciales en una página no autorizada.

También debes probar el comportamiento en el navegador y en el móvil. Una función segura sobre el papel puede tener una implementación distinta según el sistema operativo.

5. Preparar la salida

La migración debe ser reversible. Comprueba si puedes exportar la bóveda, qué formato utiliza y si la exportación permanece cifrada. Después de una migración, elimina los archivos temporales y revisa las copias creadas durante el proceso.

La dependencia total de un proveedor crea un riesgo operativo. Si la cuenta se bloquea, el servicio cambia de condiciones o la empresa deja de operar, la capacidad de recuperar las credenciales debe estar prevista.

Errores que reducen la seguridad del gestor

La herramienta no corrige todas las decisiones del usuario. Los fallos más frecuentes se concentran en la clave maestra, los dispositivos y la recuperación.

1. Usar una clave maestra breve o reutilizada. La bóveda se convierte en un único punto de fallo. La contraseña debe ser larga, exclusiva y resistente a asociaciones previsibles.

2. Guardar los códigos de recuperación dentro de la misma bóveda. Si el acceso principal se pierde, esos códigos no estarán disponibles.

3. Mantener sesiones abiertas en equipos compartidos. La protección de la cuenta termina cuando otra persona puede acceder a la sesión desbloqueada.

4. Instalar extensiones desde fuentes no verificadas. Una extensión maliciosa puede observar formularios, modificar páginas o interceptar el autorrelleno.

5. Ignorar las actualizaciones. Los gestores y sus extensiones corrigen vulnerabilidades. Retrasar indefinidamente las actualizaciones prolonga la exposición.

6. Conservar copias sin cifrar. Un archivo exportado en texto claro puede contener todas las credenciales y quedar indexado por el sistema.

7. Confundir biometría con una clave maestra independiente. La biometría puede desbloquear una sesión local, pero no sustituye el análisis de la protección de la bóveda.

8. Aceptar cualquier solicitud de autorrelleno. El usuario debe revisar el dominio y el contexto de la página antes de entregar una credencial.

9. No proteger el dispositivo. Un registrador de teclas puede capturar la contraseña maestra cuando se introduce. Ningún gestor puede garantizar la seguridad de un equipo comprometido.

10. No probar la recuperación. La pérdida del móvil, el cambio de número o el fallo de una llave física deben formar parte del plan antes de que se produzcan.

Un gestor de contraseñas concentra las credenciales. La seguridad depende de que también concentre controles, no solo datos.

Qué perfil debe tener un gestor seguro

La comparación entre productos debe terminar en una evaluación documentada. Un gestor presenta una base técnica razonable cuando combina cifrado robusto, derivación de claves, conocimiento cero, autenticación multifactor, autorrelleno sensible al dominio, auditorías externas y políticas de privacidad comprensibles.

Ningún criterio aislado resuelve la decisión:

• AES-256 o XChaCha20 describen el cifrado, pero no la gestión completa de las claves.
• Argon2 o PBKDF2-SHA256 aumentan la resistencia frente a intentos automatizados, pero no compensan una clave maestra débil.
• Código abierto mejora la revisión pública, pero no sustituye una auditoría ni un mantenimiento constante.
• MFA, FIDO2 y passkeys reducen el riesgo de acceso indebido, pero requieren recuperación segura y dispositivos protegidos.
• La nube facilita la sincronización, pero amplía la dependencia operativa.
• El almacenamiento local reduce la exposición al proveedor, pero exige copias y mantenimiento propios.
• El RGPD establece obligaciones de privacidad, pero no garantiza una implementación criptográfica concreta.

A corto plazo, la decisión más relevante consiste en eliminar la reutilización de contraseñas y proteger el acceso a la bóveda con una clave maestra exclusiva y un segundo factor. A medio plazo, el resultado dependerá de la capacidad del proveedor para mantener auditorías, corregir vulnerabilidades, comunicar incidentes y conservar una política clara de datos.

La seguridad de los gestores de contraseñas no se mide por la apariencia de la aplicación. Se audita en la arquitectura, en la autenticación, en la recuperación y en el comportamiento ante errores. El mejor gestor de contraseñas para un usuario o una organización será el que permita verificar esos controles y mantenerlos bajo supervisión continua.