¿Es posible tener un protocolo seguro de autenticación de desafío / respuesta, autenticado inmediatamente?
Demasiado lento: una solicitud de cliente - > desafío del servidor - > respuesta del cliente - > respuesta del servidor
Suficientemente rápido: solicitud de cliente - > respuesta del servidor
No. Al enviar una respuesta a la solicitud, no está desafiando al cliente, por lo que es un tipo diferente de esquema de autenticación.
El método que describe no proporciona un desafío. Puede haber credenciales proporcionadas, como un par de nombre de usuario y contraseña, pero no desafía al cliente a proporcionar nada más allá de lo que ya ha proporcionado.
Veamos un viejo ejemplo de desafío / respuesta:
mappu me envía un correo electrónico. Antes de que mi servidor lo acepte a su valor nominal, proporciona un desafío de nuevo a mappu . Ahí es donde mappu tiene la oportunidad de confirmar su identidad y permitir que el correo electrónico se envíe a mi buzón. Sin ese desafío, ya no es una autenticación de desafío.
Estas propuestas se basan en que el cliente genere tanto el desafío como la respuesta al desafío. Todos tienen desventajas.
IDEA 1:
El cliente genera nonces aleatorios de desafío. El servidor debe almacenarlos en caché para evitar los ataques de reproducción.
IDEA 2:
El cliente genera errores aleatorios de desafío junto con un parámetro de marca de tiempo. El servidor garantiza que la marca de tiempo es reciente y puede vencer los desafíos suficientemente antiguos de su caché.
IDEA 3:
El cliente genera desafíos que aumentan de manera monotónica. El servidor realiza un seguimiento de solo el último desafío y hace cumplir que no se aceptan valores que no sean de menor valor. Evita los ataques de retransmisión a pesar de almacenar solo un único valor.
Lea otras preguntas en las etiquetas authentication protocols challenge-response