¿Hay algún beneficio para continuar enviando UN / PW al servidor a través del ID de sesión (es decir, sin estado frente a estado)

1

Estaba leyendo esta pregunta sobre la sesión Secuestro de ID

y dio muchas respuestas sobre el robo de identificadores de sesión. He estado pensando en esto por un tiempo, pero ¿hay algún beneficio en usar los identificadores de sesión al volver a iniciar sesión con un combo UN / PW, o viceversa? Parece ser que el problema con los identificadores de sesión es que se puede adivinar, y en ocasiones se muestra al usuario en la línea URL con el Tipo de sesión, es decir, JSESSIONID para sesiones de servidor Java.

Tengo curiosidad si el reenvío de información UN / PW para iniciar sesión sería "más seguro" o no? Supongo que, dado que ya se envió una vez, el almacenamiento en una aplicación / cookie y su reutilización más tarde podrían ser beneficiosos, pero tal vez eso deje a la PW / UN abierta a la posibilidad de robar también.

Mi pregunta es, ¿hay algún beneficio para alguno de los enfoques? ¿Funcionaría mejor o no? Gracias.

    
pregunta XaolingBao 25.10.2016 - 20:06
fuente

1 respuesta

1

Reenviar su nombre de usuario y contraseña es un riesgo de seguridad mucho mayor y no tiene beneficios sobre los identificadores de sesión (o alguna variación de tokens de acceso) que puedo ver.

Perder una contraseña tiene un mayor impacto

Aquí se explica por qué: si tu ID de sesión está secuestrada, tu atacante tendrá acceso a tu sesión, lo cual es lo suficientemente malo. Pero si obtiene su nombre de usuario y contraseña, puede hacerse pasar por usted al servicio todo el tiempo que quiera (porque generalmente las contraseñas no caducan, a diferencia de las sesiones), puede restablecer su contraseña y bloquearlo fuera del servicio, etc. Dado que muchas personas reutilizan contraseñas en otros sitios, la obtención de su contraseña también puede comprometer sus cuentas en otros muchos sitios. No puede hacer nada de eso si solo tiene el ID de sesión. Por lo tanto, es mejor exponer el ID de sesión de corta duración, localizado al riesgo que el nombre de usuario y la contraseña de larga duración.

Lo ideal es que la contraseña nunca se transmita a través de la red (existen esquemas que evitan el envío de la contraseña y la mayoría de los navegadores y servidores web son capaces de usar los más simples (por ejemplo, la autenticación de Google Digest), pero desafortunadamente , el desarrollo de esta tecnología se ha descuidado a favor de implementar sistemas de inicio de sesión del lado del servidor utilizando pantallas de inicio de sesión atractivas, que requieren la transmisión de la contraseña.)

El secuestro de la sesión es (debería ser ...) difícil

Robar un ID de sesión no es tan fácil. Adivinar los ID de sesión es muy difícil (billones de veces más difícil que adivinar la contraseña promedio) si la aplicación que los genera lo está haciendo bien. Los ID de sesión deben crearse como cadenas aleatorias largas utilizando un generador de números aleatorios de fuerza criptográfica; y como la mayoría de las sesiones solo son válidas durante unas pocas horas como máximo, no hay mucho tiempo para hacer muchas conjeturas. Pasar los identificadores de sesión como parámetros GET en la URL es un problema, sí, pero esto debe hacerse solo para degradarse con gracia cuando el navegador del usuario no acepta cookies. La mayoría de los identificadores de sesión se pasan utilizando cookies que se encuentran en el encabezado de una solicitud http.

Autenticación y autorización federada

Finalmente, reenviar el nombre de usuario y la contraseña a menudo es simplemente imposible, ya que pueden no estar disponibles. Si utiliza la autenticación federada y sistemas de autorización como OpenID / OAuth, no tiene acceso a las credenciales del usuario; acaba de obtener un token de acceso o identificación (o ambos), que son una clase de carta notariada para demostrar que usted es quien dice ser y debe tener acceso a un determinado recurso. Nuevamente, los tokens de acceso solo son válidos por unos pocos minutos hasta una hora, y solo para un recurso específico, por lo que incluso si un token de acceso fue robado, el daño que alguien podría hacer con él sería limitado.

Con OAuth, puede solicitar un tipo especial de token llamado token de renovación que puede usar para obtener un token de acceso nuevo sin la necesidad de que el usuario vuelva a iniciar sesión cuando el token de acceso anterior caduque. Así que esto se acerca a su pregunta acerca de cómo reenviar las credenciales de inicio de sesión, porque si el token de renovación es robado, el atacante obtiene acceso casi indefinido al servicio para el cual está destinado el token. Pero tenga en cuenta que incluso cuando se roba un token de renovación (que normalmente se mantiene fuera del alcance de los agentes de usuario por parte de un servidor), esto no compromete la contraseña del usuario y todos los demás sitios para los que usa su cuenta.

APIs descansadas

A diferencia de los sitios web que permiten que un usuario inicie sesión, las API suelen ser sin estado. Por lo tanto, el cliente debe autenticarse con cada solicitud que haga a la API. Esto se puede hacer enviando el nombre de usuario y la contraseña cada vez que realice una solicitud, pero muchas API lo resuelven haciendo que un cliente obtenga primero un token de acceso con sus credenciales, y luego use el token de acceso para acceder la API. OAuth es un ejemplo perfecto para esto. De nuevo, la contraseña solo se envía una vez por "sesión" para obtener un token de acceso.

    
respondido por el Pascal 26.10.2016 - 01:12
fuente

Lea otras preguntas en las etiquetas