¿Cuáles son los pros y los contras de permitir que los usuarios permanezcan conectados a una aplicación web?

  

Estoy trabajando con cookies en PHP para un script de inicio de sesión y mi amigo cree que almacenar una contraseña con hash en una cookie es una mala noticia.

Tu amigo tiene toda la razón, no hay razón para hacer esto. No es una cuestión de permanecer conectado, es una cuestión de exponer innecesariamente el hash de la contraseña (nota al margen: utilice PHP password_hash función para las contraseñas de hashing).

Al exponer el hash de la contraseña a través de una conexión encriptada (estás usando HTTPS, ¿no?) no es el fin del mundo, el verdadero problema es que me indica que probablemente estás autentificando sesiones comparando El valor de la cookie contra el hash almacenado. Esto significa que no tiene forma de invalidar las cookies de sesión, si el hash de la contraseña está expuesto, ¡eso es todo lo que necesita un atacante para acceder a la cuenta de alguien!

Use la administración de sesión incorporada de PHP, que utiliza un valor aleatorio lo suficientemente largo para hacer un seguimiento de los usuarios (al menos en las versiones recientes, las versiones antiguas han tenido problemas con esto).

Para responder a su pregunta original de cuánto deben durar las sesiones, varía enormemente. Mi escritorio está registrado indefinidamente en mi cuenta de Gmail, pero la mayoría de los sitios bancarios caducan las sesiones después de 15-30 minutos de inactividad. Para un sitio que no tiene nada de importante, las sesiones duraderas están bien, aunque es bueno permitir que los usuarios vean las sesiones existentes en su cuenta y las caduquen manualmente.

Permitir que los usuarios permanezcan conectados para un acceso menos sensible está bien como se indica, Amazon lo hace. Sin embargo, los sitios web como ProtonMail no permiten esta opción.

  

almacenar una contraseña con hash en una cookie

Tengo un problema, solo puedo ver dos métodos para que funcione:

1. Pase el hash
2. Tratar el hash como un token de autenticación

Ambos métodos son vulnerables. Pasar el hash es esencialmente el equivalente a almacenar una contraseña de texto sin formato dentro de ese archivo de cookie. En su lugar, use la cookie para almacenar un token de autenticación . Muchos se acercan al token de manera diferente, usaré MD5 solo para fines de demostración, tenga en cuenta que se trata de una función de hashing en desuso , y no se debe usar para obtener información confidencial. Esta es una idea base común para implementar tokens de autenticación "md5 (salt + nombre de usuario + ip + sal) " . Luego puede revocar el token de la sesión al comprometerse sin necesidad de cambiar la contraseña. Además, puedes configurar los tokens para que caduquen después de X días, asegurando que los tokens de cookies anteriores sean menos propensos a ser un vector de ataque.

La gente que deja su estación de trabajo desbloqueada es una preocupación legítima. Debe usar un sistema operativo Restrive o informar a los usuarios de la interfaz acerca de OpSec. Los programas comprometidos que acceden y copian las cookies de autenticación también pueden plantear un problema. Y acceder a la unidad de almacenamiento (si no se utiliza el cifrado) cuando se apaga. Todas son preocupaciones legítimas, pero la capacitación del personal sobre la Operación de Seguridad es un factor importante.

Dividamos esto en dos preguntas:

1. Cómo conservar la sesión y por qué almacenar una contraseña con hash no es una buena idea.

   La información de sesión que le permite a un usuario autenticarse sin una contraseña a menudo se almacena en las cookies en forma de un "token de sesión". Un buen token de sesión es una cadena impredecible (por ejemplo, aleatoria criptográfica) que se asocia con un usuario en el servidor. Por lo tanto, en caso de pérdida de cookies, se puede usar en actividades maliciosas hasta que un usuario termine una sesión o se termine automáticamente. Los marcos PHP tienen herramientas de seguridad predeterminadas para implementarlo.

   Naturalmente, un usuario y un sitio web están expuestos a ciertas amenazas.

   El usuario, por un lado, puede perder el control sobre la confidencialidad de sus cookies a través de diferentes factores: virus, vulnerabilidades de seguridad del navegador, acceso físico. Todas estas cosas suceden de vez en cuando y su misión es minimizar el riesgo de perder algunos datos valiosos. Por supuesto, puede haber un virus que obtendrá un control total sobre la PC o registrará las pulsaciones de teclado, pero hay muchos escenarios menos dañinos, donde el acceso es limitado (por ejemplo, el error reciente de Safari al ejecutar un código JS arbitrario en cualquier pestaña)

   El sitio web, desde el otro lado, también puede tener vulnerabilidades de seguridad como XSS y otras que podrían resultar en la exposición de las cookies. Lo curioso es que todos los sitios web fueron o serán vulnerables en algún momento del tiempo, por lo que la misión es, nuevamente, minimizar el mal impacto.

   Ahora, si estamos almacenando una contraseña en las cookies, permitimos que un pirata informático que la ha robado tenga acceso permanente y libertad de lectura o modificación de la información a pesar de que el usuario cierre la sesión (lo que terminaría el token de sesión anterior si tuviéramos uno ) hasta que un usuario cambie la contraseña.

   Por cierto, dar a un usuario el mismo token de sesión cada vez que inicia sesión es lo mismo que almacenar sus contraseñas en cookies.

2. Por qué el tiempo de espera de la sesión es una buena práctica.

   En los malos escenarios que describí en la página 1, cuanto más larga sea la sesión activa, más tiempo podrá un atacante potencial realizar una actividad maliciosa. Entonces, la solución es limitar la vida de la sesión a un período de tiempo "relevante para la seguridad". Por ejemplo, una aplicación bancaria probablemente cerrará sesión después de 20 minutos de inactividad. Facebook almacenará su sesión durante meses, pero tiene la capacidad de rastrear todos sus inicios de sesión y finalizar cualquier sesión activa.

   No conozco los detalles específicos de su aplicación, pero si no almacena ninguna información financiera o privada, un mes para una sesión en vivo será suficiente.