it-swarm-es.com

¿Son seguros los GUID para tokens únicos?

Veo que muchos sitios usan GUID para restablecer contraseñas, solicitudes de cancelación de suscripción y otras formas de identificación única.

Presumiblemente son atractivos porque son fáciles de generar, únicos, no secuenciales y parecen aleatorios.

¿Pero son lo suficientemente seguros para estos propósitos?

Me parece que dado un GUID, puede ser posible predecir GUID posteriores ya que (hasta donde yo sé) no están destinados a ser criptográficamente seguros ... ¿o no?

Nota:

  • No estoy no hablando de sitios que usan un blob aleatorio de gobbledygook codificado en base64.
  • Estoy hablando de sitios como este que parecen estar usando un GUID sin procesar:
    http://example.com/forgotPassword/?id=b4684ce3-ca5b-477f-8f4d-e05884a83d3c
84
Michael Haren

¿Son lo suficientemente seguros para los fines que describiste? En mi opinión, generalmente 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 o seguros.

Entonces, para una función de verificación de suscripción o cancelación de 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) del RFC 4122 para GUID (o identificadores únicos universales).

42
Xander

El especificación UUID detalla varias "versiones" que son métodos para generar el UUID. La mayoría apuntan a garantizar la unicidad (ese es el punto principal de UUID) mediante, por ejemplo, la fecha actual. Esto es eficiente pero significa que si bien el UUID generado es ¡único, también es ¡predecible, lo que los hace inadecuados para algunos usos de seguridad.

El método de generación "versión 4" UUID (en la sección 4.4) , sin embargo, se supone que utiliza un generador de números aleatorios criptográficamente fuerte. 6 de los 128 bits están fijados a un valor convencional (para indicar que se trata de un UUID de la versión 4, 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), luego de muchos UUID generados, se supone que un atacante no puede predecir el siguiente con una probabilidad de éxito superior a 2-122, que es suficientemente pequeño para la mayoría de los propósitos, incluidos los códigos de lanzamiento de misiles nucleares.

122 bits aleatorios aseguran la unicidad con alta probabilidad. Si genera muchos UUID de versión 4 y los acumula, puede esperar encontrar su primera colisión después de aproximadamente 261 UUID: eso es aproximadamente 2 billones de billones; simplemente almacenar esa cantidad de UUID usaría más de 30 millones de terabytes. Si considera "solo" 1012 dicho UUID (mil miles de millones, almacenable a más de 16 terabytes), entonces los riesgos de tener dos UUID idénticos entre estos 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, UUID are apropiado para fines de seguridad if (y solo si) son UUID de "versión 4" generados con un RNG seguro.

59
Thomas Pornin

Son seguros en Windows 2000 o posterior. Su vulnerabilidad y riesgo depende de cómo se genera el GUID. Windows 2000 o posterior utiliza la versión 4 del GUID que es criptográficamente segura.

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)

5
goodguys_activate

Si está utilizando un lenguaje de desarrollo común, crear un generador de números aleatorios únicos con una función de cifrado 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 usando Google ) y, por lo tanto, usar una nueva guía simple es básicamente pereza desde el punto de vista del desarrollador.

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

1) Es realmente un valor de una sola vez que no tiene relación con la identificación del usuario, por lo que, una vez que se restableció la contraseña, ya no se puede usar

2) Tiene una ventana de tiempo definida para su validez (puede 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 restablecer la contraseña o, como Avid describe en el comentario, intente obtener acceso para restablecer la contraseña utilizando algún tipo de volver a adjuntar, entonces el diseño de la aplicación es defectuoso y usar o no usar un Guid no es el verdadero problema.

Entonces, si no está tratando con información muy sensible, entonces tal vez una guía podría funcionar, pero ¿por qué no hacer las cosas de la manera correcta la primera vez y usar una API criptográfica adecuada para generar una cadena aleatoria segura?

Saludos Massimo

3
massimogentilini

Falsos "GUID", que son no generados por cualquier algoritmo de generación GUID), pero que en cambio son simplemente 128 bits (16 bytes) generados por un PRNG criptográficamente seguro, y que simplemente se representan utilizando la codificación convencional GUID hexadecimal con guiones), son en su mayoría seguros para tokens únicos.

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 usar tokens de 256 o 512 bits, donde la existencia de una colisión es de alrededor de 2 ^ -128 o 2 ^ -256.

0
yfeldblum