¿Los GUID son seguros para tokens de una sola vez?

¿Son lo suficientemente seguros para los propósitos que describiste? En mi opinión, en general sí. ¿Son lo suficientemente seguros en aplicaciones donde la seguridad es una preocupación importante? No. Se generan utilizando un algoritmo no aleatorio, por lo que no son criptográficamente aleatorios ni seguros.

Entonces, para una función de verificación de cancelación de suscripción o suscripción, realmente no veo un problema de seguridad. Por otro lado, para identificar a un usuario de una aplicación de banca en línea (o, probablemente, incluso una función de restablecimiento de contraseña de un sitio donde la identidad es valiosa) los GUID son definitivamente inadecuados.

Para obtener más información, puede consultar sección 6 (Consideraciones de seguridad) de la RFC 4122 para GUID (o identificadores únicos universales).

La especificación UUID detalla varias "versiones" que son métodos para generar el UUID. La mayoría tienen como objetivo garantizar la singularidad (ese es el punto principal de UUID) utilizando, por ejemplo, la fecha actual. Esto es eficiente, pero significa que si bien los UUID generados son únicos , también son predecibles , lo que los hace inadecuados para algunos usos de seguridad.

El "versión 4" método de generación de UUID (en la sección 4.4) , sin embargo, se supone que debe utilizar un generador de números aleatorios criptográficamente fuerte. 6 de los 128 bits se fijan a un valor convencional (para indicar que se trata de una versión 4 UUID, a saber), por lo que esto deja 122 bits del RNG.

Si el RNG subyacente es seguro (por ejemplo, /dev/urandom en un sistema Linux / MacOS / * BSD, o CryptGenRandom() en Windows), dado que se generan muchos UUID, no se supone que un atacante poder predecir el siguiente con una probabilidad de éxito superior a 2 ^-122 , que es adecuadamente pequeña para la mayoría de los propósitos, incluidos los códigos de lanzamiento para misiles nucleares.

122 bits aleatorios aseguran unicidad con alta probabilidad. Si genera muchos UUID de la versión 4 y los acumula, puede esperar encontrar su primera colisión después de aproximadamente 2 ⁶¹ UUID: eso es aproximadamente 2 billones de billones; simplemente almacenar ese número de UUID usaría más de 30 millones de terabytes. Si considera "solo" 10 ¹² UUID (mil de billones, almacenables más de 16 terabytes), entonces los riesgos de tener dos UUID idénticos entre ellos son aproximadamente 9.4 * 10 ^-14 , es decir, alrededor de 700 mil veces menos probable que ganar millones de dólares en la lotería.

Por lo tanto, los UUID son apropiados para fines de seguridad si (y solo si) son UUID de "versión 4" generados con un RNG seguro.

Son seguros en Windows 2000 o más nuevos. Su vulnerabilidad y amp; El riesgo depende de cómo se genera el GUID. Windows 2000 o más reciente utiliza la versión 4 del GUID que es criptográficamente seguro.

Para obtener más información, consulte este enlace de MSDN y este pregunta de desbordamiento de pila . (Gracias a Jordan Rieger en los comentarios)

Si está utilizando un lenguaje de desarrollo común, crear un generador de un solo disparo de números aleatorios únicos utilizando una función criptográfica adecuada no es tan difícil (estamos hablando de 10 líneas de código que están disponibles como ejemplos en los idiomas más comunes) simplemente utilizando Google) y, por lo tanto, usar una nueva guía sencilla es básicamente la pereza desde el punto de vista del desarrollador.

En el escenario descrito, están "suficientemente seguros", si el Guid aprobado en la función de contraseña olvidada tiene algunas características básicas:

1) Realmente es un valor de un disparo que no tiene relación con el ID de usuario, por lo que, una vez que se haya restablecido la contraseña, ya no se puede utilizar

2) Tiene una ventana de tiempo definida para su validez (puedes restablecer la contraseña en los próximos 30 minutos o algo así)

Si usa el mismo Guid, puede restablecer la contraseña más de una vez o adivinar el guid y restablecer la contraseña de los usuarios que no solicitaron un restablecimiento de la contraseña o, como describe Avid en el comentario, intente obtener acceso para restablecer la contraseña usando algún tipo de conexión de reproducción, entonces es el diseño de la aplicación que está defectuoso y que usar o no usar un Guid no es el verdadero problema.

Entonces, si no estás tratando con información muy sensible, quizás un guid podría funcionar, pero ¿por qué no hacer las cosas de manera adecuada la primera vez y usar un api criptográfico adecuado para generar una cadena aleatoria segura?

Saludos Massimo

Sin embargo, te encuentras con el problema del cumpleaños, ya que la existencia de una colisión es de alrededor de 2 ^ -64 para tokens de 128 bits.

Es mejor utilizar tokens de 256 bits o 512 bits, donde la existencia de una colisión es de alrededor de 2 ^ -128 o 2 ^ -256.