falsificando un GUID

Ha declarado que está interesado en considerar tanto las colisiones generadas por medios "adecuados" como los ataques que implican la generación maliciosa de GUID de manera incorrecta. Las respuestas a estas dos situaciones son extraordinariamente diferentes.

Si todos los GUID que ingresan a su sistema se generan por medios adecuados (es decir, se generan de acuerdo con RFC 4122, entonces puede esperar que todos sean únicos. Los GUID / UUID se diseñaron desde el principio para proporcionar la garantía específica. Un GUID / Los UUID generados en cualquier lugar serán únicos de todos los demás GUID / UUID sin requerir autoridad centralizada. Hay servidores de Oracle que generan millones de UUID por segundo en bases de datos distribuidas gigantes sin colisiones. Los GUID / UUID se crearon para esto .

Si le preocupa que los usuarios malintencionados elaboren GUID / UUID de forma incorrecta, tiene alguna preocupación. De esta respuesta con respecto a los UUIDs :

  Sin embargo, los GUID

generados al llamar a las funciones de generación de GUID de otras personas aún no son adecuados para su uso como tokens de autenticación no supuestamente, ya que ese no es el propósito de la función de generación de GUID, simplemente está explotando un efecto secundario.

Esa respuesta golpeó el clavo en la cabeza. Los GUID / UUID nunca fueron diseñados para ser indiscutibles. Fueron diseñados para ser únicos. Si el método que utiliza para generar esos GUID / UUID proporciona una indiscutibilidad, es un efecto secundario del proceso. Necesitarías investigar cómo funciona tu generador en particular.

Como habrás notado, los GUID v1 son particularmente adivinables. Su singularidad depende completamente de una dirección MAC y una marca de tiempo con incrementos de 100 ns. Esto es comparativamente fácil de falsificar. Si puede reducir el tiempo en el que se generó una sesión, digamos 1/10 de segundo, solo hay 1,000,000 valores posibles. La única otra protección que tiene es el campo de secuencia de reloj, que no pretende ser indiscutible, por lo que es probable que permanezca igual entre los reinicios de una computadora.

v4, por otro lado, está casi completamente definido por un número aleatorio de 122 bits. Estos son altamente incomprensibles, siempre que pueda confiar en el generador de números aleatorios subyacente. Sin embargo, recuerde que depende de un efecto secundario del proceso aquí. La calidad de los números aleatorios no garantiza que no se requiera para generar valores únicos, solo se requiere para que no se pueda evaluar.

Como tal, si depende de la aleatoriedad de sus ID de sesión como una función de seguridad, debe generarlas usted mismo, utilizando un generador criptográfico en el que confíe. No hay nada de malo en usar el formato GUID para estos números. Todavía tendrán más que suficiente entropía para lidiar con simples claves de sesión. El truco es que no debe confiar en que los generadores GUID incorporados brinden garantías que no son parte explícita del propósito de la generación de GUID.

El problema con la determinación de la seguridad de un UUID v4 (sabemos que los UUID v1 no son seguros en absoluto) es que debe conocer y comprender el mecanismo subyacente para generarlos en su aplicación específica, ya que esto podría ser diferente para Cada implementación, y definitivamente podría tener un impacto de seguridad.

La clave es que estás buscando no solo la aleatoriedad, sino también la impredecible. Sabemos que un UUID versión 4 tiene 122 bits de aleatoriedad. Esto es muy bueno, y si la fuente de la aleatoriedad es un CSPRNG, podemos estar seguros de que sí, es bastante seguro usarlo como un identificador de sesión. Sin embargo, si el RNG es no un CSPRNG, existe una posibilidad clara de que, si bien los UUID tienen buenas propiedades de aleatoriedad estadística, todavía pueden ser lo suficientemente predecibles para un atacante que tenga en sus manos algún número de ellos para adivinar otros identificadores de sesión válidos con una probabilidad no trivial y solo una cantidad razonable de trabajo.

Entonces, si sabe cómo se generan los GUID para su aplicación, puede determinar mucho mejor si es seguro usarlos directamente para proteger los datos de la sesión.

Basado en la documentación de UuidCreate , esta respuesta sobre el tamaño de un UUID de Windows (desde Windows 2000) y esta respuesta sobre la aleatoriedad UUID , y por último el RFC referente a la creación un GUID de números aleatorios , parecería que tiene razón al afirmar que los sistemas Windows modernos generarán GUID de forma predeterminada mediante el uso de un generador de números aleatorios basado en AES, lo que debería hacer que la suplantación de identidad sea igualmente inviable en comparación con un identificador aleatorio generado a partir de el mismo CSPRNG con el mismo número de bits aleatorios (122 bits). Sin embargo, como la segunda respuesta señala, los GUID están destinados a ser únicos, no a defenderse contra la falsificación: el hecho de que lo hagan por su método de generación es efectivamente un efecto secundario.

Como programador, dos cosas me preocupan sobre el uso de GUID como identificadores de sesión aleatorios

1. Ya que realmente no podemos verificar el código fuente para las funciones subyacentes, es posible que tengan algún tipo de protección contra la generación del mismo número dos veces, lo que puede debilitarlas como verdaderos CSPRNG. En general, tampoco uso los GUID como números aleatorios en principio, porque no es su propósito documentado.

2. El uso de un GUID lo limita a la entropía en la que está programado el GUID para usar - 122 bits. Deberá volver a escribir su código en el futuro si desea comenzar a usar, por ejemplo. En su lugar, 256 bits, mientras que usar un CSPRNG ahora te permite cambiar fácilmente el tamaño del número generado más adelante.