HMAC: ¿Qué tan único debe ser un nonce si la fecha también forma parte de la firma?

Debe tener en cuenta la ventana de tiempo permitida (para compensar la desviación del reloj). Si permite las fechas con una ventana de tiempo de más / menos 10 minutos (total: 20 minutos), debe utilizar nonces que sean únicos en toda la ventana de tiempo, y también debe almacenar nonces gastados de ese período de tiempo.

Para evitar una situación de carrera en la que se elimina un nonce de la lista de "gastados" Antes de la fecha: el encabezado del nonce usado se ha vuelto inválido, se recomendaría almacenar los nonces gastados de los últimos 40 minutos, y también use nonces que son únicos durante 40 minutos.

Entonces tienes una solución prácticamente hermética.

En otras palabras, si permitiría que se reutilizara un nonce después de 1 segundo, un atacante simplemente puede reenviar la solicitud anterior con el encabezado de fecha anterior, ya que si permite una ventana de tiempo, lo cual debe hacerlo porque no puede asegurar la El reloj del cliente está sincronizado con el servidor, entonces usted aceptaría una solicitud con un nonce gastado.

Si realmente deseas una buena fuente, usa H (Time, Nonce) donde H es una función hash decente. Luego puede usar nonces "no únicos" siempre que no genere 2 nonces iguales en el mismo segundo. Entonces obtienes hashes únicos para usar como nonces.

No quiero ser franco, pero a medida que inventas tu propio algoritmo de autenticación, es casi seguro que lo estropearás y estará sujeto a muchos tipos de ataques. Le sugiero encarecidamente que estudie los trabajos de investigación disponibles y los algoritmos de autenticación criptográfica conocidos antes de crear los suyos para que sepa qué errores no cometer. Comience con la autenticación Kerberos, luego con Zero Knowledge Proofs, luego SSL / PKI.

Dicho esto, para responder a su pregunta, tanto el cliente como el servidor deben generar datos que probablemente se utilicen (o garanticen) para su ventana de tiempo. Los nonces deben usarse una vez (número una vez). Un número aleatorio suficientemente grande sirve para ese propósito y no necesita ser almacenado. Hacer que el cliente y el servidor generen un nonce (2 nonces diferentes) significa que ambos reducen la posibilidad de un ataque de repetición desde el otro lado.

Además, no desea que su servidor de autenticación se convierta en un Oracle (ayude a un cliente atacante con contraseñas de usuario que adivina) o que un servidor falsificado rompa las contraseñas de usuario (engañe a un cliente para que revele su contraseña), por lo que debe ser Cuidado con cómo diseñas tu algoritmo. El número mínimo de pasos necesarios para un algoritmo de autenticación es cuatro .

1. c-s: hola, soy cliente + nonce_c.
2. s-c: client-challenge + nonce_s.
3. c-s: cliente-respuesta + desafío del servidor.
4. respuesta del servidor.

¿Ves el algoritmo anterior? El cliente dice quién es (Paso 1), que incluye el nonce del cliente, luego (el Paso 2) el servidor le pide al cliente que demuestre algo que el servidor generó usando el nonce del cliente, un autenticador del cliente almacenado (hash de contraseña, por ejemplo) y un servidor generado mientras tanto. El paso 3 prueba el cliente al servidor. El paso 4 (que la mayoría de la gente olvida) prueba el servidor al cliente; un paso importante para proteger a sus clientes de ataques de servidores falsificados (man in the middle y dns spoofing).

Con este tipo de algoritmo, no necesita almacenar nonces o preocuparse por reutilizarlos en una ventana de tiempo. En su lugar, hágalos lo suficientemente grandes y aleatorios: juntos, el cliente y el servidor participan en la creación de un nonce con propiedades suficientemente seguras.