¿Es posible tener nonces de servidor sin estado en el Compendio HTTP?

Question

¿Es posible tener nonces de servidor sin estado en el Compendio HTTP?

#1 de Thomas Pornin (8 votos)

9

Al implementar un servidor HTTP Digest, existe el problema de los nonces.

Nonces de servidor (a diferencia de nonce de cliente)

debe ser emitido por el servidor
los clientes pueden reutilizarlos siempre que el servidor lo permita
no sabe nada sobre lo que el usuario utilizará más tarde

Una implementación ingenua es recordar todos los errores que se emiten en la memoria, pero esto introduce un estado: un cliente necesita hablar con el mismo servidor o los servidores deben compartir la lista de archivos no válidos, lo que se convierte en un problema de escalabilidad. / p>

Mi pregunta es: ¿Es posible proporcionar fuentes seguras y sin estado ? Creo que sí, y me gustaría que esté (in) validado:

Convierta el nonce en un mensaje firmado criptográficamente desde el servidor :

una marca de tiempo de caducidad (por ejemplo, 86400 segundos en el futuro)
un número aleatorio (¿quizás?)
una firma criptográfica (sha o hmac quizás?)

Todo esto podría agruparse en el nonce que se proporciona en el encabezado 401 Www-Authenticate. Cuando cualquier servidor ve esto, puede verificar la integridad del mensaje (recalculando la firma). Luego se puede verificar la marca de tiempo, y si es así, entonces el nonce es bueno.

¿Esta técnica se describe en otra parte?
¿Esta forma de proporcionar nonces derrota el propósito de los nonces?
¿Hay alguna otra forma de proporcionar autenticación HTTP Digest sin estado?

http nonce

pregunta mogsie 28.01.2012 - 01:49

fuente

1 respuesta

Lea otras preguntas en las etiquetas http nonce

negación plausible con TrueCrypt Construyendo una lista de vulnerabilidades que deben ser verificadas durante el pentest

score 8 · Accepted Answer

Si el servidor no tiene estado, se puede volver a reproducir lo que sea que los clientes envíen para "obtener autenticación". Un atacante solo tiene que espiar una solicitud de un cliente, y luego puede enviar su propia solicitud con el encabezado correspondiente simplemente copiado. Una fecha de caducidad impide que el atacante lo haga de manera indefinida, pero incluso si el atacante puede causar estragos en su servidor solo durante un día, esto todavía no es satisfactorio. La posibilidad de ataques de repetición es consustancial a la apatridia; es inevitable.

Y el Compendio HTTP no es un gran protocolo de todos modos. HTTP Digest garantiza un servicio de seguridad solo en un modelo en el que los atacantes pueden espiar los datos intercambiados, pero no alterarlos; Este no es un modelo muy realista. En la práctica, necesita algo más exhaustivo, como SSL, en cuyo punto puede enviar la contraseña tal como está (HTTP Basic) y olvidarse de HTTP Digest.