¿Cuánto tiempo debe durar un nonce aleatorio?

Un nonce de 64 bits es probablemente más que suficiente para los propósitos más prácticos, si los 64 bits son aleatoriedad de calidad criptográfica.

¿Por qué son suficientes 64 bits? Permítanme describir el tipo de razonamiento que puede usar para responder esta pregunta. Asumiré que esta es una URL de tiempo limitado de un solo uso; después de que se usa una vez, ya no es válido, y después de un tiempo (3 días, por ejemplo), caduca y ya no es válido. Dado que el nonce solo tiene sentido para el servidor, la única forma en que un atacante puede intentar adivinar es enviar la respuesta de 64 bits al servidor y ver cómo responde el servidor. ¿Cuántas conjeturas puede intentar el atacante en el tiempo antes de que caduque el nonce? Digamos que el atacante puede hacer 1000 solicitudes HTTP por segundo (que es un atacante bastante robusto); entonces el atacante puede hacer aproximadamente 1000 * 3600 * 24 * 3 = 2 ²⁸ en un período de 3 días. Cada conjetura tiene una probabilidad de 1/2 ⁶⁴ de estar en lo cierto. Por lo tanto, el atacante tiene como máximo una probabilidad de 1/2 ³⁶ de romper el esquema. Eso debería ser más que lo suficientemente seguro para la mayoría de las configuraciones.

Primero, estime la cantidad máxima de usos que obtendrá su sistema (la cantidad de veces que se generará un nonce aleatorio). A continuación, decida un nivel de seguridad aceptable, es decir, cuán improbable debe ser que un nonce sea un duplicado de uno antiguo. Calcule la cantidad de usos en bits, duplique eso y agregue la improbabilidad que necesita en bits y tendrá su longitud de nonce.

Un ejemplo de AES-GCM con IV aleatorio. El número de invocaciones permitidas con IV aleatorio para una clave determinada es 2 ^ 32. La probabilidad de que una IV se reutilice debe ser inferior a 2 ^ -32. La longitud de nonce requerida para esto es 32 * 2 + 32 == 96 bits.

Si, hipotéticamente, desearía poder generar paquetes de 2 ^ 96, cada uno con un nonce aleatorio y desearía que la probabilidad de que un nonce duplicado sea menor que 2 ^ -32, necesitaría un nonce que tiene 96 * 2 + 32 == 224 bits de longitud.

Comparando esto con la respuesta anterior de 64 bits ... si tiene más de 2 ^ 16 (65536) usos de su sistema, la probabilidad de tener un nonce duplicado en ese tiempo es más de 2 ^ -32 (más de 1 en 4 mil millones, escala corta). Esto podría ser bastante aceptable, dependiendo de sus requisitos de seguridad, o podría no serlo.

Como respuesta universal, todos los UUID aleatorios mencionados son una solución bastante buena.

Tenga en cuenta que estos valores son aproximaciones , y los cálculos más precisos son mucho más complejos.

Para restablecer la contraseña, usaría un salt en lugar de un nonce para el token. Es decir, simplemente necesita generar un Salt, almacenarlo durante un período de tiempo asociado con la cuenta de usuario y esperar a que el usuario haga clic en el enlace que contiene ese Salt. No es necesario realizar un seguimiento de estos tokens para garantizar que nunca se usen más de una vez. Una vez que se haya utilizado un token, simplemente elimínelo.

Debe usar al menos 128 bits, generados por un generador de números pseudoaleatorios criptográficamente sólido. No necesita un formato UUID, solo necesita una cadena criptoreatoria suficientemente larga.

Para las URL, puede usar la codificación base64url o la codificación hexadecimal. La codificación base64url será más corta, pero será sensible a mayúsculas y minúsculas. La codificación base64url es ligeramente diferente de la codificación base64, ya que no se necesitan = de terminación y los + y / se cambian por - y _ , cuyos caracteres no necesitan ser especialmente codificado para urls.