¿Debo usar un generador criptográfico seguro de números aleatorios cuando genero IDs?

Math.random() generalmente se inicializa desde la hora actual del día. Por lo tanto, existe la posibilidad de que ocurran colisiones para los objetos que se generan aproximadamente a la misma hora cada día.

Desde una perspectiva de seguridad, esto significa que estos valores "aleatorios" serán predecibles por un atacante.

Incluso si se incluye otra cosa, un generador de números pseudoaleatorios no criptográficamente seguro puede revelar su estado si se capturan suficientes valores. Por esta razón, desde una perspectiva de seguridad, es mejor usar solo los valores generados por un generador de números pseudoaleatorios criptográficamente seguro (por ejemplo, crypto.randomBytes() al que hace referencia).

CSPRNG s tienen ciertas propiedades que las hacen adecuadas para su uso en seguridad:

  

• Cada CSPRNG debe satisfacer la prueba del siguiente bit. Es decir, dada la   Los primeros k bits de una secuencia aleatoria, no hay tiempo polinomial   Algoritmo que puede predecir el bit (k + 1) con probabilidad de éxito.   Mejor que el 50%. Andrew Yao demostró en 1982 que un generador de paso   La siguiente prueba de bit pasará todas las demás estadísticas de tiempo polinómico   pruebas de aleatoriedad.
  
• Cada CSPRNG debe soportar "estado   extensiones de compromiso ". En el caso de que parte o todo su estado haya   revelado (o adivinado correctamente), debería ser imposible   Reconstruir el flujo de números aleatorios antes de la revelación.   Además, si hay una entrada de entropía mientras se ejecuta, debería ser   no es factible utilizar el conocimiento del estado de la entrada para predecir el futuro   Condiciones del estado CSPRNG.
  

El uso de dicho generador satisfará sus requisitos de seguridad:

• Evita la enumeración fácil.
• No regala objetos de orden fueron creado.
• No regala el número total de objetos o tasas de crecimiento.

Sin embargo, no debe permitir que el hecho de que ahora sean imprevisibles proteja el primer caso con controles de acceso adecuados (autenticación y autorización). Las URL no deben considerarse secretas y hay muchas maneras de filtrarse (navegación de hombro con cámara oculta, pérdida de encabezado de referencia HTTP, proxy y registros del navegador). Además, una vez que se conoce una URL y confía en un secreto impredecible para protegerla, el usuario que accede a ella siempre tendrá acceso y esto no se puede revocar. Recuerda, pueden marcarlo fácilmente.

El uso de valores impredecibles definitivamente ayudaría a sus otros requisitos en caso de que se consideren necesarios para su aplicación. Recomendaría usar un valor aleatorio de 128 bits que sea más que suficiente entropía para evitar la previsibilidad y las colisiones.

tl; dr: Eso depende, si puedes, usa un CSPRNG.

Aunque a menudo se utilizan UUID que no están (de lo contrario) de un CSPRNG, esto podría no ser una buena idea en los casos en que el PRNG (no CS) -PRNG no se reinicialice de manera regular (como en los procesos de servidores de larga duración )

Si el algoritmo que usa para crear dichos identificadores es conocido, y su ingreso puede estimarse con algunas muestras (como es el caso de C's rand() por ejemplo), pierde todas las propiedades que enumeró en su pregunta.

Por lo tanto, usar un PRNG predecible para generar valores a partir de una sola semilla es malo, si el PRNG malo se vuelve a sembrar con una buena entropía antes de cada uso (como es el caso habitual en la mayoría de los szenarios web), eso debería estar bien. p>

Entonces, si puedes, usa un CSPRNG. Si no puede, intente reiniciarlo con una buena entropía antes de cada paso de generación.

Todo depende de cómo se genere y se use el proceso de generación.

Si tiene un proceso de larga ejecución, haga que use un CSPRNG. Si está utilizando procesos de corta duración, use una buena fuente de entropía y básicamente cualquier PRNG.

Sí. Un RNG seguro desde el punto de vista de la criptografía es necesario para lograr todo lo que enumeró.

No sé cómo funciona Math.random, pero piense en un RNG TERRIBLE que llamaremos 2bitRNG que se siembra con solo 2 bits, pero produce números de 128 bits. Sembré 2bitRNG con mis 2 bits de entropía y luego produzco 10,000 números aleatorios con él.

Como solo lo he sembrado con 2 bits, solo hay 4 semillas posibles. Entonces, un atacante solo tiene que buscar en un espacio de 40,000 números aleatorios posibles para encontrar la semilla correcta y posicionarse en la secuencia en la que se encuentra actualmente. Es un número pequeño, y probablemente podría calcularse en una fracción de segundo con una computadora modesta. Una vez que el atacante sabe esto, sabe la siguiente secuencia y cuántos RNG ha producido.

No sé qué tan malo es Math.random ni a qué otros ataques podría ser vulnerable, pero la recomendación general es NO usarlo por razones de seguridad porque no es seguro. Un RNG seguro adecuado utiliza una gran cantidad de entropía (~ 128 bits o más) para evitar el tipo de ataque que acabo de describir y no produce resultados predecibles.

Definitivamente recomendaría el uso de un generador de números aleatorios criptográficamente seguro siempre que sea posible, independientemente de cuáles sean los datos. Las ventajas superan a las desventajas.

Además, nunca se sabe para qué se usará este código más adelante. Cuando realice revisiones de código, en la mayoría de los casos, siempre marcaré el uso de un generador de números aleatorios no criptográficamente seguro.

También puede querer ver el uso de por sesión referencias de objetos indirectos , ya que en algunos casos puede tener sentido utilizarlas. Simplemente no olvide realizar comprobaciones de autorización / privilegios antes de operar o devolver datos del cliente.

Retrocede y observa tu problema desde un punto de vista diferente. ¿Qué es lo peor que podría pasar si usas números secuenciales? Usted ha mencionado la enumeración: ¿cuál es la amenaza de la enumeración? ¿Alguien puede causar un problema si ve que usted emite los números # 00015 y # 00016, y predice que el ID # 00017 probablemente se generará a continuación? Tal vez alguien pueda secuestrar un correo electrónico o una cuenta de twitter que probablemente esté asociada con una próxima identificación.

¿Y cuál es el problema si alguien puede determinar que el ID # 00023 es anterior al ID # 42234? ¿Las ID más antiguas generalmente tienen más recursos disponibles que las ID más nuevas? Quizás sé que la ID # 00123 se emitió el 1 de mayo y la ID # 00256 se emitió el 1 de junio; Si me entero de que alguna celebridad popular anunció que se inscribieron en mayo, solo tengo 133 números para adivinar su identificación. ¿El hecho de adivinar el número de identificación de alguien puede causarle problemas a alguien, o de todos modos será información pública?

En este punto, debe comprender si los números de ID secuenciales deben mantenerse en secreto o si pueden ser públicos.

Luego, eche un vistazo a los vectores de amenazas, (si se trata de amenazas realistas), y determine los riesgos. La mayoría de estos parecen ser riesgos para sus clientes si sus identificaciones secretas se hacen públicas, y menos una amenaza para sus sistemas. Pero si no está protegiendo a sus clientes, su reputación será destruida y su empresa fracasará. Entonces, si estas son amenazas válidas, debes tomarlas en serio.

A continuación, agregue el entendimiento de que se creó un Generador de números pseudoaleatorios (PRNG) para un solo propósito específico: generar números estadísticamente bien distribuidos para modelar problemas en estadísticas. Nunca fueron creados para generar números "indescriptibles". La mayoría de los PRNG están a solo un problema matemático, además de ser un generador de números secuenciales. Puede intentar saltar a través de muchos aros de siembra para reducir la capacidad de generar números adivinables, pero ese es exactamente el problema para el que está diseñado resolver un PRNG criptográficamente seguro (CSPRNG). Los CSPRNG se diseñaron específicamente para generar números indiscutibles.

Ahora que comprende mejor algunos de los riesgos, debe comprender por qué necesita (o no necesita) proteger a sus clientes de estas amenazas; y con una mejor comprensión de las diferencias entre un PRNG y un CSPRNG, puede llegar a una decisión sólida.

Si tiene que mantener estos secretos, entonces debe usar un CSPRNG para proteger a sus clientes. Si no necesita mantenerlos en secreto, debe usar un número secuencial y reducir la complejidad de su sistema eliminando el generador de números aleatorios por completo.

Los PRNG no seguros a nivel de cifrado son vulnerables al análisis que puede determinar los parámetros que generan la secuencia. Una vez que conoce la secuencia, es posible determinar no solo el siguiente valor, sino también el número total de números de secuencia en uso. Consulte enlace para ver un ejemplo fascinante de cómo hacer esto en el mundo real.

Además de hacer que los identificadores secuenciales sean indiscutibles, también es conveniente evitar la generación del mismo identificador dos veces dentro del mismo contexto. Si utiliza un PRNG, el número de identificadores está limitado por el período del PNRG y es vulnerable a cualquier debilidad en la generación de semillas. Si utiliza un generador de números aleatorios criptográficamente seguro, el número de identificadores está limitado por el tamaño del identificador y debería ser menos vulnerable a los problemas de siembra.

Si los números se usan en un sistema cerrado donde se generan como máximo unos miles de identificadores, entonces es probable que un PRNG esté bien.

Si los identificadores deben generarse de manera distribuida y globalmente únicos, el uso de un generador de números aleatorios criptográficamente seguro ayuda a garantizar que no haya colisiones.