¿Usar el hash de contraseña como ID de sesión?

8

Para una aplicación web de cliente enriquecido, en el servidor necesito verificar que cada llamada provenga de un usuario que haya iniciado sesión legalmente. Obviamente, la identificación del usuario no es suficiente, porque es fácil de adivinar.

Tengo una idea sobre la que soy escéptico, pero no puedo pensar en razones racionales para no hacerlo.

¿El uso de contraseñas protegidas con una función hash suficientemente fuerte (bcrypt?) es un buen identificador de sesión? Ya está en DB, es único para cada usuario y no se puede adivinar fácilmente. Estoy utilizando un canal seguro (HTTPS) para todas las comunicaciones entre el cliente y el servidor, por lo que no tengo que preocuparme por interceptar el identificador de sesión.

No me importa la caducidad de la sesión, el estado o el inicio de sesión desde dos computadoras a la vez. La aplicación del servidor es lo suficientemente apátrida. Todo lo que realmente necesito es la ID de usuario y algunos medios adicionales de verificación de que ha iniciado sesión correctamente.

    
pregunta Konrad Garus 30.06.2011 - 18:32
fuente

4 respuestas

13

Un problema que podría tener con este tipo de configuración es que, por lo que ha dicho, parece que el token de sesión sería estático (es decir, para un usuario determinado, nunca cambia, hasta que cambian su contraseña). Como tal, si un atacante logra obtener acceso a un token para un usuario determinado (troyano, registrador de teclas, detección de paquetes (si no se usa SSL), etc.) tendrá acceso permanente a la aplicación.

También deberías tener más cuidado de lo habitual para asegurarte de que los tokens de sesión no se registren en ningún lado del servidor, ya que esencialmente serían tan buenos como las contraseñas.

    
respondido por el Rоry McCune 30.06.2011 - 20:45
fuente
7

No sé qué bibliotecas está utilizando para escribir su aplicación, pero la mayoría proporciona algún tipo de gestión de sesión.

La implicación de usar una contraseña tiene un token de sesión, no podrá distinguir una sesión de otra. ¿Y si dos usuarios tienen la misma contraseña? ¿Podrás notar la diferencia?

Además, se volverá vulnerable a los ataques de reproducción, a menos que elija agregar algunos datos aleatorios al token de la sesión. Esto se debe almacenar en un almacenamiento persistente en algún lugar.

Cuando ya hayas llegado tan lejos, deberías elegir generar todo el token de sesión, ya que ya necesitas, es decir, una tabla de sesión.

Para un canal HTTPS, todo vale siempre que nadie pueda leer sus cookies (¡recuerde las cookies solo https!) o adivinelas.

    
respondido por el Dog eat cat world 30.06.2011 - 18:50
fuente
4

Una buena cookie de sesión antepondrá una caducidad a los datos serializados y luego antepondrá un HMAC de la caducidad + datos serializados a la caducidad + datos serializados usando la clave secreta de la aplicación.

message = serialize_to_bytes(session_data)
random = random_bytes(16)
expiration = unix_timestamp_as_16_bytes(now + 2 * 60 * 60 /*2 hours*/)
signable = random + expiration + message
signature = HMAC-SHA256(application_key, signable)
signed_message = signature + signable

El signed_message será imperdonable. Estará sujeto a ataques de repetición durante 2 horas. Si la cookie de sesión firmada se hackea dentro de la ventana de 2 horas, la sesión podría extenderse infinitamente. Para hacerlo mejor, tendría que idear un buen esquema para los nonces. En una aplicación grande con múltiples servidores web que sirven cookies de sesión, eso requeriría una base de datos central de nonces usados, que puede ser difícil de manejar.

Asegúrese de establecer la marca secure de la cocinera (para que solo se envíe en solicitudes HTTPS) y la bandera% co_de (para que no esté disponible para JavaScript directamente).

Asegúrate de usar SSL siempre.

    
respondido por el yfeldblum 27.07.2011 - 22:23
fuente
3

El enfoque propuesto me parece un enfoque deficiente. Deja que el framework web haga la gestión de sesión por ti. Muchos marcos web ya proporcionarán soporte para la autenticación del usuario y le permitirán, en una sola llamada, consultar si hay un usuario conectado asociado con la sesión de la solicitud actual. Sólo usa eso. Rodar el tuyo es peligroso. No entiendo por qué necesita o quiere rodar algún mecanismo de propósito especial para esto.

    
respondido por el D.W. 03.08.2011 - 09:09
fuente

Lea otras preguntas en las etiquetas