Generador de Clave Determinista (PBKDF2-HMAC)

1. Derivación de clave y coste computacional (PBKDF2)

El núcleo del generador es PBKDF2 (Password-Based Key Derivation Function 2), un algoritmo estandarizado para transformar una contraseña humana en una secuencia de bits de alta calidad criptográfica. Se configura con HMAC-SHA256 como función interna y 600.000 iteraciones.

La finalidad de iterar cientos de miles de veces es imponer un coste computacional asimétrico. Para el usuario legítimo, que ejecuta la derivación una única vez, el cálculo dura una fracción de segundo. Para un atacante que intenta adivinar la Clave Maestra por fuerza bruta, cada intento requiere ese mismo cálculo completo; probar mil millones de candidatos pasa de ser cuestión de segundos a requerir hardware especializado durante meses o años.

El parámetro de 600.000 iteraciones sigue las recomendaciones actuales de OWASP para PBKDF2-HMAC-SHA256 y debe revisarse periódicamente a medida que mejora el hardware de ataque.

2. La sal criptográfica: por qué el servicio forma parte del cálculo

Una sal es un valor que se añade a la Clave Maestra antes de derivar los bits. En este generador, la sal es la concatenación del campo Servicio con el campo Versión. La Clave Maestra y la sal se introducen juntas en PBKDF2, y el resultado depende de ambas: cambiar cualquiera de las dos produce una secuencia de 512 bits completamente distinta, sin correlación aparente con la anterior.

Esto tiene dos consecuencias prácticas:

Aislamiento entre servicios. Con una única Clave Maestra, el generador produce una contraseña distinta e impredecible para cada servicio. Si un servicio sufre una filtración y un atacante obtiene la contraseña en claro, esa información no le permite deducir la Clave Maestra ni la contraseña de otro servicio: tendría que volver a ejecutar PBKDF2 (con su coste) para cada candidato de Clave Maestra que quisiera probar.

Protección frente a tablas precomputadas. Existen bases de datos precalculadas que asocian contraseñas comunes con sus hashes (rainbow tables). Al incluir un texto específico del servicio en la sal, el hash de cada servicio es distinto, y las tablas genéricas dejan de ser útiles. Un atacante tendría que precalcular una tabla específica para cada servicio concreto, lo que, combinado con las 600.000 iteraciones, resulta inviable en la práctica.

3. Sin estado: ninguna contraseña se almacena

Los gestores de contraseñas convencionales guardan una base de datos cifrada con todas las credenciales del usuario. Ese archivo puede perderse, corromperse, filtrarse o quedar inaccesible si el proveedor del servicio deja de funcionar. Recuperar el acceso depende de disponer del archivo y de la contraseña maestra que lo desbloquea.

Un generador determinista funciona de forma distinta: no almacena nada. La contraseña de un servicio no se guarda en ningún archivo ni base de datos; se recalcula bajo demanda cada vez que se necesita, a partir de la Clave Maestra y el nombre del servicio. El único dato persistente que necesita el usuario es lo que recuerda: su Clave Maestra.

Durante el uso, la contraseña generada reside únicamente en la memoria de la pestaña del navegador. Al cerrar la pestaña, desaparece. Esta página es un archivo estático que se ejecuta localmente: no envía la Clave Maestra ni la contraseña derivada a ningún servidor.

4. De bytes a caracteres: el alfabeto y el sesgo estadístico

PBKDF2 produce 64 bytes (512 bits) de salida. Estos bytes no son directamente una contraseña: cada byte es un número entre 0 y 255, y hay que convertirlos en caracteres pertenecientes al alfabeto permitido.

El alfabeto por defecto contiene 74 caracteres: las 26 letras mayúsculas, las 26 minúsculas, los 10 dígitos y 14 símbolos de uso común (!@#$%^&*()_+-=). Se han seleccionado símbolos ampliamente aceptados por los formularios web; se excluyen caracteres que causan problemas frecuentes en URLs, shells, SQL o sistemas de archivos.

La conversión de un byte a un carácter del alfabeto se hace mediante el operador módulo:

Aplicado ingenuamente, este método introduce un sesgo estadístico (modulo bias): como 256 no es múltiplo de 74, los primeros índices del alfabeto aparecen con una probabilidad ligeramente superior a los últimos. Para eliminar este sesgo, el generador calcula el mayor múltiplo de 74 que cabe por debajo de 256 (en este caso, 74 × 3 = 222) y descarta cualquier byte con valor igual o superior. Solo los bytes aceptados se traducen a caracteres, garantizando que todos los caracteres del alfabeto son equiprobables.

Este descarte consume entropía: algunos de los 64 bytes se desechan. Si los requisitos exigen más caracteres de los que la entropía disponible puede producir, el generador lo señala con el error "Entropía agotada".

5. Uso de versiones (recomendado)

El campo Versión es un número entero que forma parte de la sal criptográfica. Modificarlo regenera una contraseña completamente distinta, sin relación con las versiones anteriores, dentro del mismo espacio de 2⁵¹² posibilidades.

La versión es el mecanismo preferido para manejar dos situaciones:

Renovación periódica. Si se necesita cambiar la contraseña de un servicio (por política interna, por sospecha de exposición, o por decisión del usuario), basta con incrementar el número de versión. La nueva contraseña no tiene relación derivable con la anterior.

Servicios con políticas restrictivas. Algunos servicios rechazan contraseñas por no cumplir sus reglas: exigen al menos un símbolo, un número o una mayúscula. En lugar de forzar la composición mediante restricciones manuales, el procedimiento recomendado es incrementar la versión hasta que la contraseña generada cumpla los requisitos del servicio. Como la derivación es determinista, la próxima vez que se necesite esa contraseña basta con probar versiones crecientes desde 1 hasta dar con la que se aceptó. No hace falta recordar el número: se redescubre reproduciendo el mismo procedimiento.

El uso de versiones es preferible a las restricciones manuales porque no reduce la entropía de la contraseña. Cada incremento de versión sortea una contraseña nueva en el espacio completo de posibilidades, sin imponer ninguna estructura sobre su composición.

6. Restricciones manuales (uso avanzado)

Los cuatro campos bajo Restricciones (A-Z, a-z, 0-9, Símbolos) tienen dos modos:

Modo automático (campo vacío, placeholder "-"). El generador muestra en el campo el recuento real de caracteres de cada clase en la contraseña generada. Es informativo, no impone ninguna condición.

Modo manual (el campo aparece con borde naranja cuando contiene un número distinto de cero). El generador exige ese mínimo de caracteres de la clase correspondiente. Si la contraseña producida por el método natural no cumple la condición, se activa el Modo Adaptado: se extraen del flujo de bytes los caracteres obligatorios de cada clase, se rellena el resto con caracteres del alfabeto completo, y finalmente se aplica el algoritmo de barajado Fisher-Yates usando los bytes restantes como fuente de aleatoriedad para las posiciones de intercambio. El resultado es una contraseña que cumple las restricciones y cuyo orden no presenta patrones previsibles. Introducir 0 o dejar vacío el campo lo devuelve a modo automático.

Las restricciones manuales deben usarse solo cuando sea estrictamente necesario, por dos motivos:

Son frágiles de recordar. Para regenerar la misma contraseña en el futuro, el usuario debe recordar no solo el servicio y la versión, sino también el valor exacto de cada restricción activa. Un único valor distinto produce una contraseña completamente diferente.

Reducen ligeramente la entropía. Imponer una composición fija (por ejemplo, "exactamente 2 mayúsculas, 2 números y 2 símbolos") restringe el conjunto de contraseñas posibles al subconjunto que cumple esas condiciones, reduciendo el espacio efectivo de búsqueda frente a una contraseña sin restricciones.

El caso de uso legítimo para las restricciones manuales es un servicio que impone una política concreta y rígida imposible de satisfacer con el método de versiones: por ejemplo, "exactamente 3 símbolos, ni uno más ni uno menos".

7. Guía práctica de uso

Paso 1. Elegir una Clave Maestra. Debe ser larga, memorable y usarse exclusivamente aquí. Una frase de varias palabras no relacionadas es una opción razonable. Esta es la única credencial que el usuario debe recordar; si se olvida, no hay forma de recuperar ninguna de las contraseñas derivadas.

Paso 2. Introducir el nombre del servicio. Debe seguirse un criterio consistente (por ejemplo, el dominio principal en minúsculas: google.com, github.com). El indicador CHK junto a la Clave Maestra muestra un hash corto de 4 caracteres que permite verificar visualmente que se ha tecleado la clave correcta.

Paso 3. Ajustar longitud y versión. La longitud por defecto es 16; puede aumentarse hasta 64 si el servicio lo permite. La versión inicial es 1 y solo debe modificarse si hace falta regenerar la contraseña.

Paso 4. Copiar y usar. El botón de copiado lleva la contraseña al portapapeles. Al cerrar la pestaña, la contraseña desaparece de la memoria del navegador.

Paso 5. Si el servicio rechaza la contraseña. Incrementar el número de versión hasta que la contraseña generada cumpla los requisitos del servicio. Recordar (o anotar) qué versión fue aceptada, o simplemente probar desde 1 la próxima vez.

Qué memorizar por cada servicio: idealmente, nada más allá del nombre del servicio. Si se usa una versión distinta de 1, recordar también ese número, o estar dispuesto a redescubrirlo probando versiones crecientes.