Generar contraseñas seguras personalizadas y evaluar la fortaleza criptográfica.
Cómo se calcula la fortaleza real de una contraseña, por qué el generador del navegador importa y qué prácticas descartó el NIST.
Para una contraseña elegida al azar sobre un alfabeto de N símbolos y longitud L, la entropía es H = L × log2(N) bits. Con los 94 caracteres imprimibles de ASCII, log2(94) ≈ 6,55 bits por carácter: 12 caracteres dan 78 bits y 16 caracteres, 105 bits. Si el alfabeto se reduce a minúsculas y dígitos (N = 36, 5,17 bits por carácter), hacen falta 21 caracteres para llegar a esos mismos 105 bits. La fórmula solo es válida cuando cada carácter se sortea de forma independiente y uniforme: "Verano2024!" tiene 11 caracteres, pero su entropía efectiva ronda los 20 bits porque sigue un patrón que las reglas de hashcat generan en segundos.
Math.random() en V8 usa xorshift128+, un generador con 128 bits de estado pensado para velocidad. Devuelve dobles de 52 bits y su estado interno se puede reconstruir observando unas pocas salidas consecutivas, lo que permite predecir toda la secuencia en ambos sentidos. La primitiva correcta es crypto.getRandomValues(), alimentada por el CSPRNG del sistema operativo. Hay un error clásico incluso usándola: hacer bytes[i] % alfabeto.length introduce sesgo modular cuando 256 no es múltiplo de la longitud del alfabeto. Con 94 caracteres, 256 = 2 × 94 + 68, así que los primeros 68 símbolos aparecen con probabilidad 3/256 y los otros 26 con 2/256, un tercio menos. La solución es descartar los bytes por encima del múltiplo mayor y volver a muestrear.
La revisión de NIST SP 800-63B retiró tres costumbres heredadas: las reglas de composición obligatoria (al menos una mayúscula, un dígito y un símbolo), la caducidad periódica sin indicio de compromiso y las preguntas de seguridad. En su lugar pide aceptar entre 8 y al menos 64 caracteres, permitir todo el ASCII imprimible y Unicode, no truncar la entrada y comparar cada contraseña nueva contra listas de credenciales filtradas. Para el almacenamiento exige una función de derivación de clave con sal y coste ajustable —PBKDF2, bcrypt, scrypt o Argon2id—, nunca SHA-256 a secas, y limitar los intentos fallidos. La rotación obligatoria queda reservada a los casos con evidencia de filtración.
Depende de cómo se guarde el hash. Una GPU moderna prueba del orden de 10^11 candidatos por segundo contra MD5 o SHA-1 sin sal, pero apenas unos miles por segundo contra bcrypt con factor de coste 12. Por debajo de 50 bits una contraseña cae en días frente a un hash rápido; 80 bits dejan fuera cualquier ataque offline realista, y 128 bits es el margen habitual para claves maestras y secretos de firma.
Se pueden comparar con la misma fórmula. Seis palabras tomadas al azar de la lista Diceware de 7776 entradas dan 6 × log2(7776) ≈ 77,5 bits, casi lo mismo que 12 caracteres aleatorios de ASCII completo (78 bits). La frase ocupa unos 28 caracteres y se memoriza; la cadena corta es preferible cuando la guarda un gestor. Lo decisivo es que las palabras se sorteen con un CSPRNG, no que las elija una persona.
Ampliar el alfabeto de 62 a 94 caracteres suma log2(94/62) ≈ 0,6 bits por carácter: en una contraseña de 12 caracteres son unos 7 bits, lo mismo que añadir un solo carácter más. Las sustituciones tipo "a" por "@" o "o" por "0" no aportan nada medible, porque los ataques por diccionario aplican esas mismas reglas de mutación antes de recurrir a la fuerza bruta. Alargar siempre rinde más que complicar.
Identificadores v4 con 122 bits aleatorios y v7 ordenados por tiempo.
Abrir herramienta →AUTHInspeccioná tokens y comprobá firmas HS256 con el secreto generado.
Abrir herramienta →DEVUsuarios y credenciales sintéticas para poblar entornos de prueba.
Abrir herramienta →