La mayoría de los gestores de contraseñas son bases de datos. Uno guarda secretos, el programa cifra el archivo y lo sincroniza en algún lado. La seguridad de todo el sistema descansa en que ese archivo cifrado siga estando cifrado.
Un gestor determinista funciona distinto. No guarda nada. Recibe una semilla, un sitio y un nombre de usuario, y deriva una contraseña a partir de esos tres datos. Si mañana recibe los mismos datos, produce la misma contraseña. No hay bóveda que robar, porque no hay bóveda.
Para quien ya tiene bitcoin en autocustodia, la idea va a resultar familiar: es el mismo truco que una seed phrase BIP39 derivando una cantidad ilimitada de claves. Esa similitud es justamente lo que lo hace atractivo para gente que ya se hizo amiga de respaldar una semilla.
También es la razón por la que conviene tener cuidado. La contrapartida es real, y la mayoría de los artículos la pasa por alto.
Cómo funciona la derivación
El mecanismo es un hash con clave. A grandes rasgos:
contraseña = KDF(semilla_maestra, sitio + usuario + nonce)
- semilla_maestra - un único secreto con mucha entropía. En las implementaciones basadas en BIP39 son las 12 o 24 palabras de siempre.
- sitio + usuario - el contexto, para que
github.com/aliceygithub.com/bobden contraseñas distintas a partir de la misma semilla. - nonce - un contador que arranca en 0. Existe para poder rotar.
- KDF - una función de derivación de claves, que convierte esos datos en una salida de longitud fija que después se codifica al conjunto de caracteres que exija el sitio.
Como un hash es determinista, los mismos datos siempre producen la misma salida. Como es de una sola dirección, quien tenga la salida no puede volver hacia atrás hasta la semilla. No hace falta guardar nada entre sesiones: el gestor vuelve a calcular la contraseña cada vez.
La KDF no es un detalle, y es la parte que hay que revisar en cualquier implementación. Un hash simple es rápido, y rápido es justo lo que quiere un atacante: quien consiga una sola contraseña derivada, de un sitio que la guardó mal o de una página que la pescó, puede probar candidatos de secreto maestro sin conexión, verificando cada intento al derivar la contraseña de un sitio que ya conoce. Una semilla real de doce palabras queda muy lejos de eso. Una contraseña maestra elegida por una persona, no, y por eso las implementaciones serias usan una función deliberadamente lenta, PBKDF2 con muchas iteraciones, scrypt o Argon2, en lugar de un SHA-256 pelado.
El resultado es una herramienta que puede correr completamente sin conexión, desde un solo archivo HTML, sin cuenta, sin sincronización y sin servidor.
Lo que realmente se gana
No hay bóveda que vulnerar. La pesadilla recurrente de la industria de gestores de contraseñas es que se filtre la bóveda cifrada y después la ataquen con calma, sin apuro. LastPass informó en diciembre de 2022 que un atacante había copiado un respaldo de datos de bóvedas de clientes, que es exactamente esa forma. Un gestor determinista no tiene ese archivo.
Sin sincronización, sin confianza en terceros. No hay proveedor del que depender, ni suscripción que se venza, ni servicio que cierre y se lleve las credenciales.
Un solo respaldo cubre todo. Si ya se construyó la disciplina para guardar una seed phrase, se está reutilizando esa disciplina en lugar de sumar un segundo problema de respaldo distinto.
Auditable en una tarde. Estas herramientas son chicas. Toda la lógica entra en una página de código, lo cual es una propiedad valiosa para algo que sostiene todas las credenciales que uno tiene.
Lo que cuesta
Esta es la sección que decide si la herramienta sirve o no en cada caso.
La semilla pasa a ser un único punto de falla total. No "algunas cuentas": todas las cuentas, al mismo tiempo, en silencio. Con una bóveda, el atacante necesita el archivo y la contraseña maestra. Acá, la semilla sola reconstruye todo, y no queda ninguna señal de que pasó.
La rotación es contabilidad que ahora es responsabilidad de uno. Al cambiar una
contraseña hay que recordar que github.com/alice está en nonce 3 mientras todo lo demás
está en 0. Ese estado tiene que vivir en algún lado. En el momento en que se guarda, se
reintrodujo el archivo que se quería evitar. Y si se pierde, no se pueden regenerar
contraseñas que ya están en uso.
No se puede importar. Cada contraseña existente hay que cambiarla por una derivada, de a una cuenta por vez. Todo lo que no se pueda cambiar (una cuenta de trabajo bajo la política de otra persona, un banco que manda el PIN por correo) hay que guardarlo en otro lado. La mayoría termina con dos sistemas en paralelo.
Las reglas de contraseñas de los sitios pelean contra el diseño. Longitudes máximas, caracteres especiales obligatorios, caracteres prohibidos y reglas que cambian con el tiempo obligan al codificador a tener manejo específico por sitio. Ese manejo también es estado.
Un compromiso obliga a rehacer todo. Si se filtra la semilla, no existe el paso de "cambiar la contraseña maestra". Todas las contraseñas derivadas quedan comprometidas y todas las cuentas hay que cambiarlas a mano.
Las credenciales compartidas no funcionan. No hay forma de compartir un acceso con una pareja o un equipo sin compartir la semilla, y eso comparte todo.
Dónde queda todo esto
La derivación determinista le calza bien a una persona específica: alguien cómodo con la disciplina de una seed phrase, con una cantidad manejable de cuentas, que rota poco, que no comparte credenciales y que no quiere depender de ningún proveedor.
Le calza mal a la mayoría, y el motivo no es criptográfico. Una bóveda cifrada bien administrada, con una contraseña maestra fuerte y un segundo factor por hardware, le da mejores resultados a la gente común, porque sobrevive a los errores que las personas efectivamente cometen: olvidarse dónde quedó la lista de nonces, necesitar compartir un acceso, cambiar una contraseña a las apuradas.
Ninguna de las dos opciones es descuidada. Fallan distinto, y hay que elegir la falla con la que uno pueda vivir.
Mirar una implementación
PasswordManagerWeb es una herramienta chica de este tipo, basada en navegador, y leerla vale más que la descripción de arriba, porque es justo donde la descripción deja de coincidir con el código. Verificado contra el repositorio el 20 de agosto de 2026:
- No usa una función de derivación de claves. La contraseña son los primeros dieciséis caracteres hexadecimales de un único SHA-256 sin sal sobre la clave, el usuario, el sitio y el nonce, entre un prefijo fijo y un sufijo fijo. No hay factor de trabajo, y todas las contraseñas que produce tienen la misma forma reconocible.
- No usa la derivación de semilla de BIP39. Arma la clave concatenando la posición de cada palabra en la lista BIP39 como dígitos decimales y leyendo el resultado como hexadecimal. Las palabras son de BIP39, la derivación no, así que ninguna otra herramienta BIP39 reconstruye la misma clave desde el mismo respaldo. Ese respaldo solo sirve en esta herramienta.
- Ya no es una herramienta sin almacenamiento. El README documenta respaldos opcionales en Nostr y una copia cifrada opcional de los datos de sesión, incluido el diccionario de nonces, en el almacenamiento del navegador.
- No hay archivo de licencia, hay una sola persona contribuyendo y no hay revisión independiente. El último commit es de septiembre de 2025.
Nada de eso significa que el autor haya hecho algo mal, y que el código sea lo bastante corto como para leerlo de una sentada es precisamente el motivo para leerlo. Sí significa que no debería sostener credenciales reales, y la distancia entre lo que se dice que hace una herramienta de este tipo y lo que hace su código es la razón por la que existe la lista de abajo.
Antes de confiarle cuentas reales a cualquier herramienta de contraseñas:
- Leer la derivación misma, y confirmar que corre una KDF lenta y con sal, no un hash pelado.
- Verificar que tenga licencia, para saber qué está permitido hacer con ella.
- Verificar si alguien independiente revisó el código de derivación.
- Correrla sin conexión, desde una copia local, y confirmar que no hace pedidos de red.
- Derivar una contraseña dos veces, en dos sesiones separadas, y confirmar que da el mismo resultado antes de cambiar una sola cuenta real.
- Probar la recuperación desde el respaldo en otra máquina, antes de depender de ella.
Esto último es todo el partido. Un esquema de derivación que no se puede reproducir desde el respaldo no es un gestor de contraseñas: es una forma de perder todas las cuentas la misma tarde.
Sobre las herramientas basadas en navegador
Todo lo que corre en un navegador hereda el modelo de amenaza del navegador: extensiones con acceso a la página, una pestaña comprometida, una actualización envenenada de una página cargada desde la red. Si se usa una de estas herramientas, conviene guardar la página localmente, abrirla desde el sistema de archivos y comprobar que funciona con la red apagada. Una herramienta que solo es segura sin conexión debería usarse efectivamente sin conexión.
Relacionado: generación de billeteras y entropía cubre la misma pregunta, de dónde sale el azar de un secreto y cómo saber que es real, pero para claves de Bitcoin en lugar de contraseñas.
Corrección, 20 de agosto de 2026. Este post presentaba originalmente a PasswordManagerWeb como una implementación legible de la derivación descrita arriba. Al leer el código, no lo es: hashea sus entradas con un único SHA-256 sin sal en lugar de usar una función de derivación de claves, y mapea la seed phrase a una clave concatenando los índices de las palabras BIP39 en vez de usar la derivación de BIP39, así que el respaldo no se puede restaurar con ninguna otra herramienta BIP39. El post también decía, sobre las herramientas de este tipo, que no hay bóveda que robar; ese proyecto sumó después respaldos opcionales en Nostr y almacenamiento cifrado opcional en el navegador, así que eso ya no lo describe. La sección fue reescrita y la herramienta ya no se ofrece como implementación de referencia.