Hay una escena que probablemente hemos repetido cientos de veces.
Una página nos pide crear una contraseña. Debe tener cierta cantidad de caracteres, una mayúscula, una minúscula, un número, quizás un símbolo. Entonces hacemos lo que podemos: tomamos una palabra que conocemos, cambiamos una letra por un número, agregamos un signo de exclamación y esperamos recordar el resultado dentro de seis meses.
Durante años hemos tratado este pequeño ritual como una responsabilidad personal. Si alguien utiliza el nombre de su perro, su cumpleaños o la misma contraseña en cinco servicios distintos, solemos concluir que está haciendo algo mal.
Pero quizás existe otra forma de mirar el problema.
Estamos pidiéndole a un cerebro humano que fabrique y memorice decenas —a veces cientos— de secretos suficientemente impredecibles como para resistir a máquinas capaces de probar cantidades enormes de combinaciones.
La contradicción se vuelve más evidente cuando descubrimos que incluso las recomendaciones técnicas han cambiado. La versión vigente de las guías de identidad digital del NIST estadounidense no recomienda obligar a mezclar mayúsculas, minúsculas, números y símbolos. De hecho, dice expresamente que los servicios no deberían imponer esas reglas de composición. Para contraseñas utilizadas como único factor pide al menos 15 caracteres, recomienda bloquear claves conocidas o comprometidas y señala que los servicios deberían permitir gestores, autocompletado y pegado de contraseñas.
Es una pequeña inversión de perspectiva.
Tal vez llevamos mucho tiempo confundiendo hacerle difícil la contraseña al usuario con hacerle difícil el ataque a una computadora.
Nuestra seguridad digital no debería depender únicamente de que alguien sea incapaz de adivinar nuestro cumpleaños, nuestro color favorito o el nombre de nuestro perro.
Entonces aparece la pregunta: ¿qué debería ocupar ese lugar?
Una contraseña no debería ser una adivinanza
Conviene separar dos cosas que suelen mezclarse.
Una es la contraseña que nosotros conocemos. Otra muy distinta es la manera en que el servicio debería almacenarla.
Un sistema razonablemente diseñado no debería guardar una tabla que diga simplemente:
usuario: maria@example.comcontraseña: Toby2026!
Tampoco basta con decir que las contraseñas están “cifradas”.
Para almacenar contraseñas existen funciones específicamente diseñadas para transformarlas en verificadores mediante hashing. Antes de calcular ese hash, el sistema añade a cada contraseña una sal: un pequeño valor aleatorio y único para cada cuenta. La sal no necesita mantenerse secreta; su función es conseguir que dos personas que utilicen exactamente la misma contraseña produzcan hashes diferentes, evitando que un atacante pueda comparar fácilmente resultados o reutilizar tablas de contraseñas calculadas de antemano.
A esto se suma un factor de costo computacional, que obliga al sistema a dedicar deliberadamente más trabajo a cada cálculo. La intención es sencilla: si alguien roba la base de datos, no basta con disponer de los hashes y probar millones de claves rápidamente; cada intento debe calcularse de nuevo para cada usuario y costarle tiempo y recursos a la computadora atacante.
NIST describe precisamente ese objetivo: cada intento realizado sobre una base de hashes robada debe hacerse suficientemente costoso como para elevar considerablemente el precio de un ataque offline. También recomienda aumentar ese costo a medida que mejora la capacidad de cómputo disponible.
Aquí aparece una diferencia importante entre la seguridad humana y la seguridad computacional.
La buena seguridad no intenta inventar una adivinanza especialmente ingeniosa.
Intenta convertir cada intento del atacante en trabajo.
Aun así, seguimos teniendo un problema. Incluso si cada servicio almacena correctamente nuestras claves, todavía somos nosotros quienes debemos crearlas. Una contraseña distinta, larga y aleatoria para cada cuenta sería una buena defensa contra la reutilización, pero es incompatible con algo bastante elemental: necesitamos recordarlas.
Ahí entra el gestor de contraseñas.
La bóveda
Un gestor introduce una idea casi paradójica: para dejar de reutilizar nuestras contraseñas, las reunimos todas en un mismo sitio.
A primera vista puede sonar como construir una caja fuerte llena de todas nuestras llaves y luego colocarla en medio de Internet.
Pero el mecanismo cambia algo fundamental. Ya no necesitamos que cada contraseña sea memorable. Puede ser generada aleatoriamente, ser diferente para cada servicio y tener una longitud que resultaría absurda para la memoria humana.
Nosotros recordamos —dependiendo del sistema— una contraseña maestra, utilizamos un dispositivo o autorizamos el acceso mediante otro mecanismo. El gestor se encarga del resto.
La guía utilizada como punto de partida para esta investigación distingue varias familias: gestores alojados por un proveedor, gestores locales, soluciones autoalojadas, llaves físicas y sistemas basados en passkeys. Cada modelo intercambia de manera diferente comodidad, sincronización, responsabilidad y control.
Un gestor integrado como Apple Passwords o Google Password Manager reduce gran parte de la configuración porque ya vive dentro del ecosistema que usamos. Un servicio especializado puede funcionar entre sistemas operativos diferentes. Un gestor local puede conservar la bóveda solamente donde decidamos.
No existe aquí una propiedad mágica llamada “seguridad” que permita ordenar todas esas alternativas de mejor a peor.
Cada una desplaza responsabilidades.
La nube puede facilitarnos sincronización, recuperación y mantenimiento. Una bóveda local puede darnos más control, pero también convertir nuestra copia de seguridad en nuestra responsabilidad. Autoalojar puede reducir la dependencia de un proveedor y, simultáneamente, convertirnos en administradores de un servidor que necesita actualizaciones, respaldos y vigilancia.
Por eso la pregunta interesante no es simplemente si centralizar cien secretos es peligroso.
También habría que preguntar:
¿es más peligroso guardar cien secretos diferentes dentro de una bóveda bien protegida o intentar recordar cien secretos nosotros mismos?
No existe una respuesta independiente del usuario, del software y de las amenazas que queremos evitar.
Pero el problema de la memoria humana sí comienza a desaparecer.
Y entonces ocurre algo todavía más extraño: podemos eliminar incluso la contraseña que utilizamos frente a muchos servicios.
Una passkey no es una contraseña sofisticada
Una passkey cambia el modelo.
Con una contraseña existe un secreto que podemos escribir, copiar, revelar accidentalmente o entregar a una página falsa. Con WebAuthn y las passkeys entramos en criptografía de clave pública.
Simplificando mucho, se genera un par de claves relacionadas matemáticamente. El servicio conserva la pública. El autenticador controla la privada. Cuando queremos ingresar, el servicio envía un desafío y nuestro autenticador demuestra criptográficamente que posee la credencial adecuada.
El servidor puede verificar esa demostración sin que necesitemos entregarle una contraseña reutilizable.
Además, la credencial está asociada al servicio para el cual fue creada. Esa relación con el dominio es precisamente una de las características que hace a WebAuthn resistente al phishing: una página falsa no puede simplemente convencernos de escribirle el secreto correcto. FIDO describe las passkeys como credenciales basadas en pares criptográficos, resistentes al phishing y disponibles tanto en modalidad sincronizada como vinculada a un dispositivo concreto.
El estándar que hace posible buena parte de este mecanismo acaba de alcanzar además un nuevo hito. El 25 de agosto de 2026, W3C publicó Web Authentication Level 3 como recomendación oficial. WebAuthn define cómo una aplicación web crea y utiliza estas credenciales públicas asociadas a un autenticador y a un servicio determinado.
Hay aquí una precisión importante.
A veces se dice que “la clave privada nunca sale del dispositivo”. Eso describe bien las credenciales vinculadas a hardware específico, pero resulta demasiado simple cuando hablamos de passkeys sincronizadas. Una passkey puede ser transportada de forma protegida entre nuestros dispositivos mediante un proveedor de credenciales.
Lo fundamental es otra cosa: el sitio al que entramos no recibe un secreto reutilizable equivalente a una contraseña.
La seguridad deja de depender de nuestra habilidad para esconder una palabra y pasa a depender de una arquitectura criptográfica.
Entonces, ¿mi cara es mi contraseña?
No exactamente.
Cuando un iPhone muestra Face ID antes de utilizar una passkey, resulta natural imaginar que nuestra cara está siendo enviada al servicio para demostrar quiénes somos.
El modelo FIDO funciona de otra manera.
La biometría puede utilizarse localmente para comprobar que la persona que sostiene el dispositivo está autorizada para utilizar la credencial almacenada allí. FIDO señala explícitamente que la información biométrica y su procesamiento permanecen en el dispositivo; el servidor recibe la confirmación necesaria para completar la autenticación, no nuestra huella o nuestro rostro.
Por eso conviene separar las capas:
la biometría puede autorizarnos frente al dispositivo;
la passkey autentica criptográficamente al dispositivo o proveedor frente al servicio.
Desde fuera todo ocurre en un segundo y parece simplemente “entrar con la cara”. Por debajo hay hardware, software, estándares, claves públicas, claves privadas y protocolos negociando nuestra identidad.
La interfaz vuelve invisible la complejidad.
Y eso es precisamente parte de su éxito.
Una llave que podemos llevar en el bolsillo
Existe otra posibilidad: sacar parte de esa infraestructura del teléfono y colocarla físicamente en nuestras manos.
Las llaves de seguridad compatibles con FIDO —como YubiKey, Nitrokey, SoloKeys y otros dispositivos— pueden almacenar credenciales vinculadas al hardware. Algunas se conectan por USB, otras permiten NFC.
La idea resulta casi anacrónica y al mismo tiempo muy moderna: para entrar a determinada cuenta hay que poseer físicamente una llave.
FIDO considera que las passkeys vinculadas a hardware de este tipo pueden ofrecer niveles particularmente altos de garantía porque la credencial permanece ligada al autenticador físico.
Pero la física trae consigo sus propias condiciones.
Las cosas pueden perderse.
Una llave puede quedar olvidada en un hotel, dañarse o encontrarse a miles de kilómetros cuando la necesitamos. Por eso una configuración seria necesita mecanismos de recuperación y, para determinadas cuentas, puede justificar registrar más de una llave.
Otra vez aparece la misma estructura: cada aumento de seguridad modifica también nuestras responsabilidades.
No existe una solución sin consecuencias.
Hemos eliminado parte del secreto, no la confianza
Hasta aquí la historia parece puramente técnica.
Las contraseñas dependen demasiado de nosotros. Los gestores permiten convertirlas en secretos aleatorios. Las passkeys reemplazan el secreto compartido por criptografía asimétrica. La biometría permite autorizar localmente el uso de una credencial. Una llave física puede mantenerla ligada a un objeto concreto.
Parecería una trayectoria progresiva desde sistemas débiles hacia sistemas más fuertes.
Pero al retirar a la memoria humana del centro del sistema aparece otra pregunta:
¿en quién confiamos ahora?
No podemos auditar personalmente cada algoritmo criptográfico que utilizamos. Tampoco verificamos el código de nuestro sistema operativo cada mañana, fabricamos nuestros propios chips o inspeccionamos físicamente los servidores que sincronizan nuestras credenciales.
Delegamos.
Niklas Luhmann entendía la confianza precisamente como una forma de reducir complejidad: nos permite actuar sin poseer toda la información necesaria para reconstruir personalmente aquello de lo que dependemos. La sociedad moderna puede hacerse más compleja precisamente porque no necesitamos comprobarlo todo desde cero antes de realizar cada acción.
Un gestor de contraseñas es una pequeña máquina de reducción de complejidad.
Confiamos en que su criptografía esté correctamente implementada, que sus actualizaciones no introduzcan vulnerabilidades graves, que nuestros dispositivos permanezcan protegidos y que los mecanismos de recuperación funcionen cuando realmente los necesitemos.
Con una solución autoalojada no eliminamos esa confianza. Simplemente desplazamos una parte hacia nosotros mismos.
Seguimos dependiendo del sistema operativo, del hardware, de bibliotecas criptográficas, de quienes mantienen el software y de estándares construidos durante décadas por comunidades enteras.
La independencia absoluta probablemente sea una fantasía.
Pero de ahí no se deduce que todas las dependencias sean equivalentes.
Poder cambiar la cerradura
Imaginemos que utilizamos el mismo gestor durante diez años.
Allí ya no tenemos veinte credenciales, sino cientos. Contraseñas, notas de recuperación, códigos de autenticación y cada vez más passkeys.
En algún momento queremos marcharnos.
Entonces descubrimos si realmente poseíamos nuestras credenciales.
Durante buena parte de la historia de los gestores, trasladar contraseñas significaba exportar archivos CSV o JSON, importarlos en otro software y después borrar cuidadosamente esos archivos porque acabábamos de crear una copia legible de algunas de las llaves más importantes de nuestra vida.
Las passkeys hicieron que ese problema fuera todavía más serio. Si queríamos reemplazar las contraseñas mediante credenciales criptográficas, pero esas credenciales quedaban encerradas para siempre dentro del proveedor que las creó, habríamos ganado resistencia al phishing a costa de construir otra forma de dependencia.
La industria está comenzando a resolverlo.
FIDO Alliance desarrolla dos piezas complementarias: Credential Exchange Format (CXF), que define cómo representar credenciales como contraseñas y passkeys, y Credential Exchange Protocol (CXP), pensado para trasladarlas de manera segura entre aplicaciones. A septiembre de 2026, CXF 1.0 figura como Proposed Standard, mientras CXP continúa publicado como Working Draft. Es una distinción importante: el objetivo de interoperabilidad está mucho más avanzado que hace algunos años, pero no debemos confundirlo todavía con una capacidad universal disponible en cualquier plataforma y proveedor.
Lo interesante es que ya existen implementaciones reales.
Apple incorporó en sus sistemas versión 26 una transferencia directa entre gestores participantes. El sistema operativo actúa como intermediario, autentica el proceso localmente y evita escribir las credenciales en un archivo de exportación tradicional. Apple lo describe explícitamente como una forma de transferir contraseñas y passkeys entre aplicaciones compatibles.
Google Password Manager permite actualmente en Android importar y exportar contraseñas y passkeys directamente con otros gestores compatibles; Google también identifica esta capacidad como implementación del estándar Credential Exchange de FIDO.
1Password ofrece transferencia mediante Credential Exchange en sus aplicaciones móviles compatibles y permite mover passkeys junto con otros datos.
Bitwarden también documenta importación y exportación mediante CXP en plataformas móviles compatibles, incluido el traslado directo desde Apple Passwords hacia Bitwarden sin crear primero un archivo intermedio.
El panorama sigue siendo desigual. Proton Pass, por ejemplo, permite guardar passkeys y ofrece mecanismos amplios de exportación, incluidos archivos JSON protegidos mediante PGP, además de formatos sin cifrar para migraciones; su documentación actual de exportación sigue describiendo principalmente ese modelo basado en archivos.
Eso significa que la cerradura empieza a poder cambiarse.
Todavía no siempre. Todavía no de la misma manera. Pero algo conceptualmente importante está ocurriendo:
la portabilidad de una credencial empieza a convertirse en una propiedad de seguridad.
Antes de entrar, saber cómo salir
Eso cambia también la manera en que podríamos evaluar un gestor.
Normalmente preguntamos cuánto cuesta, si funciona en nuestro teléfono o si puede rellenar automáticamente una contraseña.
Quizás deberíamos añadir un pequeño protocolo de salida:
- ¿Puedo exportar mis contraseñas?
- ¿En qué formatos puedo hacerlo y qué información se pierde?
- ¿Puedo trasladar también mis passkeys?
- ¿Existe transferencia directa o debo crear archivos sin cifrar?
- ¿Puedo conservar una copia de seguridad independiente?
- ¿Cómo recuperaré el acceso si pierdo todos mis dispositivos?
- ¿Puedo proteger el propio gestor mediante autenticación resistente al phishing?
- ¿Podría abandonar este servicio sin reconstruir manualmente toda mi identidad digital?
La cuarta pregunta merece especial atención.
Los archivos CSV son útiles precisamente porque prácticamente cualquier software puede entenderlos. Pero esa interoperabilidad tiene un precio: normalmente contienen las credenciales en texto legible. Google aconseja eliminar el archivo después de importar las contraseñas; 1Password advierte que sus exportaciones convencionales pueden quedar sin cifrar; Bitwarden ofrece además exportaciones JSON protegidas mediante contraseña para reducir ese riesgo.
Una migración mal hecha puede convertir nuestra búsqueda de soberanía en el momento de mayor exposición de toda la bóveda.
Por eso el protocolo de salida no es un detalle administrativo.
Antes de entrar a un gestor conviene saber cómo salir de él.
Dependencias sustituibles
Ivan Illich utilizó el concepto de herramientas convivenciales para pensar tecnologías que ampliaran la capacidad autónoma de actuar de las personas, en lugar de convertirlas únicamente en consumidores dependientes de sistemas que otros controlan. Su idea de autonomía era interesante precisamente porque no equivalía al aislamiento: hablaba de libertad individual dentro de la interdependencia.
Esa distinción resulta especialmente útil aquí.
No necesitamos fabricar nuestro propio gestor de contraseñas para conservar autonomía, del mismo modo que no necesitamos fabricar nuestra cerradura, fundir nuestras propias llaves o inventar personalmente el mecanismo interno que protege nuestra casa.
Dependemos de otros para casi todo.
La pregunta es qué clase de dependencia estamos construyendo.
Un buen sistema puede permitirnos delegar aquello que una máquina hace mejor: generar secretos impredecibles, ejecutar criptografía, sincronizar credenciales o verificar firmas.
La autonomía no exige necesariamente recuperar todas esas tareas.
Quizás exige algo menos heroico y mucho más práctico:
que nuestras dependencias puedan ser sustituidas.
Delegar en un proveedor no significa automáticamente perder control. De hecho, para muchas personas delegar mantenimiento, copias de seguridad y sincronización puede producir una seguridad real mucho mayor que intentar administrarlo todo personalmente.
El problema aparece cuando la delegación se vuelve irreversible.
Cuando abandonar una plataforma implica perder nuestras credenciales, reconstruir cientos de accesos o depender de la autorización de la empresa para recuperar aquello que utilizamos para demostrar quiénes somos, la relación cambia.
Ya no tenemos simplemente una herramienta.
La herramienta comienza a tenernos a nosotros.
Entonces, ¿necesitamos un gestor de contraseñas?
La pregunta inicial ya no admite una respuesta tan interesante como parecía.
Mientras sigamos utilizando contraseñas, un gestor permite hacer algo que nuestra memoria realiza muy mal: mantener una credencial distinta, extensa e impredecible para cada servicio. NIST incluso recomienda que los sistemas permitan su utilización.
Pero el horizonte parece ir más allá del gestor entendido solamente como un depósito de passwords.
Los mismos programas están convirtiéndose en gestores de credenciales: almacenan contraseñas, passkeys, códigos, claves y mecanismos de recuperación. Y cuanto más importante se vuelve esa bóveda, menos suficiente resulta preguntar únicamente qué tan difícil es abrirla.
Tenemos que preguntar también quién puede moverla.
Durante siglos hemos confiado nuestra seguridad física a tecnologías que casi ninguno de nosotros sabe fabricar. Compramos una cerradura producida por una empresa, utilizando metales extraídos y procesados por desconocidos, basada en mecanismos diseñados por especialistas que jamás conoceremos.
No sentimos que por eso hayamos renunciado a la puerta de nuestra casa.
Seguimos teniendo algo decisivo.
Las llaves.
Y si mañana dejamos de confiar en esa cerradura, podemos quitarla y colocar otra.
Quizá nuestra identidad digital debería aspirar al mismo principio.
No necesitamos comprender cada ecuación criptográfica ni mantener personalmente cada servidor para conservar una forma razonable de autonomía. Podemos confiar, delegar y utilizar infraestructuras construidas por otros.
Pero deberíamos poder cambiar de cerradura.
Porque quizá la pregunta importante nunca fue quién guarda nuestras contraseñas.
Quizá sea si seguimos teniendo las llaves suficientes para marcharnos.
