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

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.

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.

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.

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.