Gestores de contraseñas:

cómo funcionan por dentro y cómo elegir uno

Privacidad digital  |  unfantasmaenelsistema.com

Si has leído nuestros artículos sobre Hashcat y sobre fuerza bruta con Hydra, ya sabes la mala noticia: una GPU moderna prueba miles de millones de combinaciones por segundo contra un hash filtrado, y las contraseñas que un humano puede memorizar —incluso las que parecen «raras»— caen en minutos u horas. Reutilizar la misma en varios sitios multiplica el daño: una sola brecha en un foro cualquiera acaba abriendo tu correo y tu banco mediante credential stuffing.

La respuesta razonable a ese escenario no es «inventar contraseñas más listas», porque no existen contraseñas memorizables lo bastante buenas para todo. La respuesta es delegar: que un programa genere una contraseña larga y aleatoria distinta para cada servicio, la guarde cifrada y la escriba por ti. Este artículo explica qué hace un gestor de contraseñas por dentro —el modelo de conocimiento cero, la clave maestra, el cifrado— y qué mirar antes de confiarle todas tus llaves.

1. Qué problema resuelve exactamente

Un gestor de contraseñas es una base de datos cifrada —a menudo llamada bóveda o vault— que almacena credenciales, notas seguras y otros secretos. Sobre esa idea básica añade tres funciones que son las que de verdad cambian tu postura de seguridad:

• Generación: crea contraseñas aleatorias de 20 o más caracteres, o frases de varias palabras, sin sesgo humano y distintas para cada sitio
• Almacenamiento cifrado: todo se guarda cifrado con una clave que se deriva de tu clave maestra, la única que tú memorizas
• Autocompletado con verificación de dominio: rellena las credenciales solo en la web correcta, lo que además te protege de páginas de phishing que imitan a la legítima

El intercambio es claro: pasas de recordar decenas de contraseñas mediocres a recordar una sola muy buena. Eso concentra el riesgo en un punto, y por eso el diseño interno del gestor —cómo protege esa clave maestra— es lo que hay que entender antes de elegir.

2. Conocimiento cero: el proveedor no puede leer tu bóveda

«Conocimiento cero» (zero-knowledge) significa que todo el cifrado y descifrado ocurre en tu dispositivo, y que el proveedor del servicio nunca ve ni tu clave maestra ni el contenido en claro. Lo que se sincroniza a sus servidores es un bloque cifrado que, sin tu clave maestra, es ruido.

En la práctica esto se implementa separando dos cosas que se derivan de la misma clave maestra pero nunca se envían juntas: una clave de cifrado que no sale de tu equipo y sirve para abrir la bóveda, y un hash de autenticación distinto que se manda al servidor solo para demostrar que tienes derecho a descargar el blob cifrado. El servidor valida el segundo sin poder deducir el primero.

3. De la clave maestra a la clave de cifrado: el KDF

Tu clave maestra no se usa directamente para cifrar. Primero pasa por una función de derivación de clave (KDF, key derivation function), cuyo trabajo es transformar una contraseña relativamente corta en una clave criptográfica y, sobre todo, hacer ese proceso deliberadamente lento y costoso. Así, aunque un atacante consiga tu bóveda cifrada, cada intento de adivinar la clave maestra le cuesta tiempo y memoria en lugar de ser instantáneo.

3.1 Los KDF que verás

La diferencia entre PBKDF2 y Argon2id no es teórica. PBKDF2 solo consume CPU, y una GPU con miles de núcleos prueba muchísimos candidatos en paralelo. Argon2id obliga a usar una cantidad grande de memoria por intento, lo que estrangula ese paralelismo y encarece enormemente el ataque por diccionario descrito en el artículo de Hashcat.

3.2 El caso LastPass (2022): por qué las iteraciones importan

En 2022 un atacante robó una copia de seguridad de las bóvedas de clientes de LastPass. Las bóvedas estaban cifradas, así que la seguridad de cada usuario dependía por completo de la fuerza de su clave maestra y del número de iteraciones de PBKDF2 aplicadas. El problema: muchas cuentas antiguas seguían configuradas con valores de iteraciones muy bajos —del orden de 5.000 o incluso 1— heredados de años atrás y nunca actualizados automáticamente. Para esas cuentas, un ataque de fuerza bruta offline contra la clave maestra era mucho más viable de lo que los usuarios creían. Además, ciertos campos como las URLs guardadas no estaban cifrados, lo que daba al atacante un mapa de a qué servicios apuntaba cada bóveda.

4. Cifrado local frente a sincronización en la nube

Hay dos grandes familias de gestores y conviene no mezclarlas mentalmente:

• Fichero local (KeePass, KeePassXC, KeePassDX): la bóveda es un archivo .kdbx en tu disco. Tú decides si lo sincronizas —y cómo— con tu propia nube (Nextcloud, Syncthing, un USB). Máximo control, más fricción entre dispositivos
• Servicio sincronizado (Bitwarden, 1Password, Proton Pass y similares): el proveedor aloja el blob cifrado y lo sincroniza en todos tus dispositivos y navegadores. Más cómodo; añade al proveedor como actor en el que confías para la disponibilidad y para que el cliente que te sirven no sea malicioso

En ambos casos el contenido va cifrado de extremo a extremo. La diferencia real está en quién custodia el fichero y en la superficie de ataque: un servicio popular es un objetivo más goloso, pero también suele tener más recursos de seguridad, auditorías y respuesta a incidentes que tu carpeta sincronizada casera.

4.1 Self-hosted: el término medio

Si quieres la comodidad de la sincronización sin depender de una empresa, puedes autoalojar el servidor. Vaultwarden es una reimplementación ligera y compatible con los clientes de Bitwarden, pensada para correr en un contenedor en tu servidor o en un mini-PC en casa. Sigues necesitando copias de seguridad, HTTPS con un certificado válido y mantener el software al día: te conviertes en tu propio proveedor, con lo bueno y lo malo de eso.

# Vaultwarden en Docker, expuesto SOLO en la red local (sin abrir a internet)
docker run -d --name vaultwarden \
  -e SIGNUPS_ALLOWED=false \
  -v /srv/vaultwarden/data:/data \
  -p 127.0.0.1:8080:80 \
  vaultwarden/server:latest
 
# Un proxy inverso (Caddy, nginx) delante para servir HTTPS con certificado propio.
# Copia de seguridad = copiar /srv/vaultwarden/data completo, cifrado, con regularidad.

5. El autocompletado que comprueba el dominio frena el phishing

Esta función se percibe como comodidad, pero es una defensa de seguridad de primer orden. La extensión del gestor asocia cada credencial a un dominio concreto. Cuando llegas a una página, solo ofrece rellenar las credenciales si el dominio coincide exactamente con el guardado.

Si recibes un correo que te lleva a paypa1-seguridad.com en lugar de paypal.com, tu ojo puede que no note la diferencia, pero el gestor sí: no reconocerá el dominio y no autocompletará nada. Ese «por qué no me sale la contraseña aquí» es una señal de alarma valiosísima. Por eso conviene acostumbrarse a dejar que el gestor escriba por ti y desconfiar cuando no lo hace, en vez de copiar y pegar a mano —que anula esta protección—.

6. TOTP integrado: cómodo, pero piensa dónde lo guardas

Muchos gestores pueden almacenar también los códigos de un solo uso basados en tiempo (TOTP), el segundo factor de tipo «código de 6 dígitos que cambia cada 30 segundos». Es muy cómodo: el gestor rellena usuario, contraseña y código de una vez.

El matiz de seguridad: si guardas la contraseña y el segundo factor en la misma bóveda, un atacante que abra esa bóveda tiene ambos factores. Se pierde parte del sentido de tener dos factores independientes. No hay una respuesta única —para la mayoría de cuentas, un gestor bien protegido con TOTP dentro sigue siendo enormemente mejor que no usar segundo factor—, pero para tus cuentas más críticas (el propio correo de recuperación, el banco, la cuenta que protege al resto) tiene sentido guardar el TOTP en una app aparte, o mejor usar una llave física, como se explica en el artículo sobre passkeys y FIDO2.

7. Qué pasa si el proveedor sufre una brecha

Conviene tener el modelo mental correcto. Si roban los servidores de un gestor de conocimiento cero bien diseñado, lo que el atacante obtiene son bóvedas cifradas. A partir de ahí:

• Con una clave maestra larga, única y un KDF moderno bien parametrizado, forzar esas bóvedas offline es económicamente inviable: el cifrado aguanta
• Con una clave maestra débil o reutilizada, o un KDF con parámetros antiguos, algunas bóvedas caerán —el atacante prioriza las más fáciles—
• Los metadatos no cifrados (correos de contacto, en algunos casos URLs, marcas de tiempo) pueden quedar expuestos y alimentar campañas de phishing dirigidas

8. Cómo elegir uno

No se trata de recomendar una marca —hay varias opciones sólidas y la mejor depende de tu situación—, sino de saber qué preguntar:

8.1 Buenas prácticas una vez elegido

• Clave maestra: una frase de 4-5 palabras aleatorias que no uses en ningún otro sitio; escríbela una vez en papel y guárdala en un lugar físico seguro
• Activa segundo factor para la cuenta del propio gestor (llave FIDO2 si es posible)
• Haz una exportación cifrada de respaldo cada cierto tiempo y guárdala offline
• Usa el informe de seguridad del gestor para detectar contraseñas reutilizadas, débiles o aparecidas en filtraciones, y ve corrigiéndolas
• Revisa y elimina entradas antiguas: la bóveda también es superficie de exposición

8.2 Hacia dónde va esto: passkeys

La tendencia de 2025-2026 es sustituir la contraseña por passkeys: pares de claves criptográficas resistentes al phishing por diseño, que muchos gestores ya almacenan y sincronizan igual que una credencial. No sustituyen al gestor —lo convierten en el sitio donde viven tus passkeys—, y durante años convivirán con las contraseñas de toda la vida. Lo desarrollamos en el artículo dedicado a passkeys y FIDO2.

Conclusión

Un gestor de contraseñas no es magia: es una base de datos cifrada cuya seguridad se apoya en dos pilares que ahora ya sabes evaluar —lo fuerte que sea tu clave maestra y lo moderno que sea el KDF que la protege— más un modelo de conocimiento cero que impide al proveedor leer tu contenido.

Frente a un mundo donde una GPU rompe contraseñas humanas en minutos y donde reutilizarlas convierte una brecha ajena en un problema tuyo, delegar la generación y el almacenamiento en una herramienta así es de las mejores decisiones de seguridad que puedes tomar. La única condición es entender qué estás concentrando en ese único punto y protegerlo a la altura.

unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)