¿Cómo asegurar una conexión websocket con desafío-respuesta?

Question

¿Cómo asegurar una conexión websocket con desafío-respuesta?

#1 de Steffen Ullrich (2 votos)

2

TL; DR Dado que toda la información de estado de un navegador web es accesible para un usuario (potencialmente hostil), ¿cómo puede considerarse segura la autenticación de respuesta-desafío entre el navegador y el servidor?

La versión más larga

Estoy desarrollando una aplicación web y quiero implementar sockets web para la comunicación entre el cliente y el servidor. Estoy considerando la implementación de un enrutador WAMP y estoy tratando de entender los modos de autenticación con un sistema como este.

El protocolo WAMP permite la autenticación de desafío-respuesta (CRA). La forma en que lo entiendo (y por favor me corrige si tengo este error), cuando un cliente realiza una solicitud de conexión, el servidor envía un desafío. Luego, el cliente encripta el desafío usando una clave secreta que se comparte entre el cliente y el servidor y la devuelve. El servidor verifica la versión encriptada del cliente y, si se cifró correctamente, permite el acceso. El uso de un secreto compartido permite al servidor saber que la solicitud provino de un cliente autorizado.

Esto conduce a pregunta # 1 : el código Javascript enviado al navegador debe contener el secreto compartido. Entonces el secreto compartido no es muy secreto, ¿verdad? Entonces, ¿cómo podemos considerar esto como un método seguro de autenticación?

Al pensar en esta pregunta, he encontrado una solución que creo que podría resolver el problema.

Nota importante: todas las conexiones se protegerán a través de TLS.

Así es como podría funcionar mi sistema de autenticación:

el usuario inicia sesión a través del método de autenticación normal basado en formularios
el servidor genera una clave de autenticación y un secreto, y pasa esos valores al cliente como parte de la página HTML. La clave y el secreto se generan a través de un método criptográficamente seguro.
el cliente luego inicia la conexión websocket. Esto comienza la secuencia de autenticación de desafío-respuesta, utilizando la clave y el secreto generado por el servidor
el servidor se autentica, usando la tecla & secreto, y todo está bien.

La clave aquí es el uso único de los valores clave y secreto. Si cambian periódicamente, entonces no hay forma de que un atacante pueda generar un par clave / secreto o usar uno que haya guardado de una visita anterior.

Lo que me lleva a la pregunta # 2 : ¿es este un esquema de autenticación adecuado?

Y finalmente, pregunta # 3 : suponiendo que el esquema de autenticación descrito anteriormente sea adecuado, ¿con qué frecuencia deberían cambiar los valores clave / secreto? Estoy pensando que definitivamente debería cambiar cada vez que el usuario inicia sesión, y también debería expirar después de que hayan transcurrido 6-8 horas. ¿Pensamientos?

web-application challenge-response websocket

pregunta Kryten 01.09.2015 - 15:52

fuente

1 respuesta

Lea otras preguntas en las etiquetas web-application challenge-response websocket

Autenticación mutua en OpenVPN Riesgo asociado con nonce y hash encontrado en url

score 2 · Answer 1

Esto lleva a la pregunta # 1: el código Javascript enviado al navegador debe contener el secreto compartido. Entonces el secreto compartido no es muy secreto, ¿verdad? Entonces, ¿cómo podemos considerar esto como un método seguro de autenticación?

Si estudia la de la autenticación de respuesta de desafío con WAMP deberías notar la siguiente información:

El cliente y el servidor comparten un secreto. El secreto nunca viaja por cable,

En su lugar, se considera que el secreto se compartió antes de realizar la autenticación:

El intercambio previo real del secreto está fuera del alcance del mecanismo de autenticación.

En caso de usar Websockets desde el navegador, eso probablemente significa que el código que contiene el secreto debe transferirse con TLS. Al utilizar Websockets dentro de una aplicación independiente enviada al usuario, el secreto puede enviarse previamente dentro de la aplicación. Dado que el secreto en sí no es específico del usuario, sino que solo se utiliza para asegurar la comunicación, se puede intercambiar antes de cualquier tipo de autenticación.

Nota importante: todas las conexiones se protegerán a través de TLS.

WAMP-CRA está diseñado explícitamente para ser utilizado con no TLS. De la documentación:

... por lo tanto, WAMP-CRA se puede usar a través de conexiones no TLS

Por supuesto, WAMP-CRA se puede usar con TLS, pero si tiene una conexión segura ya no necesita usar un protocolo diseñado para funcionar dentro de las limitaciones de no TLS, pero podría usar una autenticación mucho más simple como las basadas en cookies o hacer uso de la autenticación mutua proporcionada por TLS.

... Lo que me lleva a la pregunta # 2 ... Y finalmente, la pregunta # 3:

Dado que su suposición original era errónea, no es necesario agregar seguridad al protocolo existente. Por lo tanto, no cubro estas partes de la pregunta que tratan sobre la seguridad de la capa de autenticación agregada.

Pero una respuesta más general, independiente del marco que usa: Websockets es un canal de comunicación creado mediante la actualización de una conexión HTTP existente. Esto significa que cualquier tipo de autenticación realizada para la conexión HTTP (s) se puede aplicar a la conexión Websocket, es decir, autenticación TLS mutua, Autenticación básica , cookies de sesión, etc. Por lo tanto, si la conexión HTTP (s) ya está autenticada, no es necesario realizar una autenticación adicional dentro del canal Websockets porque esta es la misma conexión TCP / TLS que ya estaba autorizada.