Generador de contraseñas

El número bajo el medidor es entropía en bits, y mide el generador, no la cadena que salió. Esa distinción importa: esta herramienta sabe que la contraseña se ha elegido uniformemente al azar de un conjunto de tamaño conocido, así que log2(conjunto^longitud) es exactamente correcto. Un comprobador que mira una contraseña inventada por alguien solo puede adivinar, y le dará encantado a «Verano2024!» una nota que no se ha ganado. El tiempo estimado de descifrado supone un ataque sin conexión a diez mil millones de intentos por segundo, que es más o menos una GPU moderna contra una base de datos mal cifrada: pesimista a propósito.

Los conjuntos de caracteres son lo que permite que un solo formulario haga el trabajo de varios, y el modo PIN es esa misma idea hecha explícita: solo dígitos, de tres a doce, con los ceros a la izquierda conservados. Esto último importa más de lo que parece, porque un generador que se come un cero inicial elimina una décima parte de los valores posibles de un PIN de cuatro cifras. Los PIN elegidos por personas se agrupan muchísimo — 1234, 1111, 0000 y los años de nacimiento que empiezan por 19 cubren una proporción alarmante de los PIN reales — así que sortear uno vale los dos clics. Un PIN es débil por construcción de todas formas: cuatro dígitos son diez mil posibilidades, suficiente donde algo limita los intentos e inútil donde un atacante prueba libremente.

En el otro extremo, un secreto que solo tiene que leer una máquina puede ser tan largo y feo como quieras. El objetivo habitual para una clave de API o un token de sesión son 128 bits, que veinte caracteres del conjunto completo superan con margen. Solo letras y dígitos si el valor tiene que sobrevivir a una URL o a un intérprete de comandos sin escapes; el conjunto de símbolos es la parte que da problemas en tránsito. Los alfabetos con nombre hacen ese trabajo de forma explícita: hex lleva cuatro bits por carácter, base32 cinco, base58 y base62 algo menos de seis, y un UUID versión 4 unos fijos 122. Treinta y dos caracteres hex son el objetivo de 128 bits escrito como la mayoría de las API esperan recibirlo, y base58 es el que hay que elegir cuando una persona tiene que leer el valor en voz alta, porque deja fuera el 0, la O, la I y la l.

Las palabras son la misma aritmética un nivel más arriba, y son el modo para el puñado de contraseñas que tecleas a mano en lugar de pegar. Cada palabra vale log2 del tamaño de la lista: esta página saca de unas 48.500 palabras inglesas de cuatro letras o más, que son 15,5 bits cada una, así que cinco palabras son unos 78 bits y seis son 93. La lista está en inglés, y eso es deliberado: la entropía es una propiedad del sorteo y no de si reconoces las palabras, así que cinco palabras te dan los mismos 78 bits las entiendas o no. Lo que el modo de palabras compra es que puedas recordarlas, y esa es la parte que se pierde si no hablas el idioma; si no puedes pronunciar la frase, coge veinte caracteres al azar y guárdalos en el gestor. Diceware construyó la idea alrededor de una lista de 7.776 palabras y dados físicos, a 12,9 bits por palabra; aquí el sorteo es el mismo procedimiento con crypto.getRandomValues en lugar de los dados. El separador y las mayúsculas no añaden nada que un atacante no dé por supuesto. El número final es la excepción y el medidor lo cuenta: se sortea al azar entre 10 y 99, que son log2(90) de verdad, unos 6,5 bits.

La longitud casi siempre es la palanca más barata. Pasar de 62 caracteres en el conjunto a 87 compra alrededor de medio bit por carácter, mientras que cuatro caracteres más compran casi veinticuatro. Por eso la guía actual del NIST sube la longitud mínima y quita las reglas de composición, y no al revés.