Math.random() no es seguro para contraseñas: la solución Web Crypto

La generación de tokens aleatorios es un pilar fundamental en la seguridad de aplicaciones modernas. Sin embargo, no todas las funciones de aleatoriedad son adecuadas para este propósito. Durante años, Math.random() ha sido la opción predeterminada en JavaScript por su simplicidad, pero su uso en contextos de ciberseguridad representa un riesgo real. Este artículo explora por qué esta función no debe emplearse para contraseñas o tokens de sesión, y cómo la Web Crypto API ofrece la solución correcta. Además, abordaremos dos errores comunes al implementar alternativas seguras y cómo las empresas pueden integrar estas prácticas en sus aplicaciones a medida.

El problema de Math.random()En motores como V8 (Chrome y Node.js), Math.random() utiliza el algoritmo xorshift128+, un generador pseudoaleatorio con 128 bits de estado interno. Aunque sus números pasan pruebas estadísticas y parecen aleatorios, son deterministas. Con suficientes muestras consecutivas (entre 64 y 128 llamadas), un atacante puede recuperar el estado interno mediante herramientas públicas y predecir todos los valores futuros. Para una animación o una simulación esto es irrelevante, pero para generar contraseñas, claves API o tokens de restablecimiento, la predecibilidad es una vulnerabilidad crítica. En Q2BSTUDIO, al realizar auditorías de ciberseguridad, encontramos con frecuencia este patrón en desarrollos propios, lo que demuestra la necesidad de educar a los equipos técnicos.

La solución: crypto.getRandomValues()La Web Crypto API proporciona un generador criptográficamente seguro (CSPRNG) que extrae entropía del sistema operativo (por ejemplo, /dev/urandom en Linux o BCryptGenRandom en Windows). No existe estado recuperable; observar salidas pasadas no revela información sobre futuras. El uso básico es sencillo: crear un Uint32Array de un elemento, llamar a crypto.getRandomValues() y después reducir el valor al rango deseado. Sin embargo, surgen dos gotchas que incluso desarrolladores experimentados pasan por alto.

Gotcha 1: Sesgo de móduloAl aplicar el operador módulo sobre un número aleatorio, la distribución puede desviarse si el rango del generador no es múltiplo exacto del alfabeto. Por ejemplo, al usar un solo byte (0-255) con un alfabeto de 62 caracteres, algunos símbolos aparecen un 25% más a menudo. La solución teórica es el muestreo por rechazo: descartar valores en la cola sesgada y volver a generar. Sin embargo, si se utiliza un entero de 32 bits (rango hasta ~4.29 mil millones) y un alfabeto de 94 caracteres, el sesgo es minúsculo (0.0000022%). En la práctica, para contraseñas humanas, ese nivel de ruido es irrelevante, por lo que muchos equipos omiten el rechazo para mantener el código simple. No obstante, en contextos de ia para empresas o generación de claves criptográficas, se recomienda aplicar el rechazo para eliminar cualquier sesgo.

Gotcha 2: Límite de 64 KB por llamadaLa especificación de getRandomValues() limita las solicitudes a 65.536 bytes (64 KB) por invocación. Si se necesita generar un lote grande de tokens o llenar un buffer extenso, es necesario dividir la petición en fragmentos más pequeños. Este límite está documentado pero suele omitirse en tutoriales básicos, provocando errores silenciosos o excepciones QuotaExceededError. Una función auxiliar que itere en bloques de 64 KB resuelve el problema. Al diseñar software a medida para clientes que manejan grandes volúmenes de tokens de autenticación, en Q2BSTUDIO incorporamos estas comprobaciones para garantizar robustez.

Más allá del token: capas de seguridadUna contraseña generada con un CSPRNG soluciona el problema de predecibilidad, pero no protege contra phishing, credenciales reutilizadas o filtraciones de bases de datos. La estrategia correcta combina varias capas: usar un gestor de contraseñas, activar la autenticación de dos factores con hardware, y aplicar políticas de rotación. En el ámbito de los servicios cloud AWS y Azure, la generación segura de tokens es solo un eslabón de la cadena de seguridad. Asimismo, los servicios inteligencia de negocio como Power BI requieren tokens de acceso robustos para proteger datos sensibles.

En Q2BSTUDIO integramos estas prácticas en todos nuestros desarrollos, desde sistemas de autenticación para agentes IA hasta plataformas de automatización de procesos. La generación de tokens seguros es un ejemplo de cómo pequeños detalles técnicos pueden tener un gran impacto en la ciberseguridad general de un producto. Incluso en proyectos de inteligencia artificial, donde la aleatoriedad se usa para simulaciones o generación de datos, recomendamos evitar Math.random() cuando la seguridad sea relevante.

La lección fundamental es que el código que 'funciona' no siempre es el correcto. Math.random() funciona; crypto.getRandomValues() es correcto. En un mundo donde las amenazas evolucionan constantemente, elegir las herramientas adecuadas marca la diferencia entre una aplicación vulnerable y una robusta.