01 octubre 2009

El problema de la des-autenticación

Leyendo un artículo de Bruce Schneier, famoso gurú de la seguridad, nos recuerda cosas que efectivamente se suelen dejar un poco de lado en algunas ocasiones.
Inicialmente, los proyectos de autenticación, para cualquier tipo de sistema, se suelen afrontar con preguntas tales como: ¿cuántas vueltas de llave y con cuántas llaves va a haber involucradas? ¿se usarán esquemas de autenticación fuerte? ¿smartcards con certificados digitales? ¿One-time password? ¿autenticación de varios factores? ¿biometría?...

Pero, una vez definido y resuelto cuántos y cuáles son los mecanismos a utilizar, se suele uno relajar. Sin embargo, hay que definir claramente cómo se lleva a cabo el fin de la sesión. como dice Bruce: "cómo se entera el otro extremo de la comunicación de que tú ya no estás ahí". Aquí se pueden tener en cuenta dos tipos de problemas: cuando pulsas el botón "fin de la sesión" (o logout); y cuando te vas a tomar un café, a comer o incluso terminas tu trabajo y te vas a casa y dejas la sesión abierta.

En el primero de los casos, el darle al botón de finalizar sesión, debería finalizar las transacciones pendientes para ese usuario (que tengan que devolver algún tipo de comunicación en esa sesión), invalidar las cookies para ese cliente (para permitir por ejemplo el acceso a otro usuario desde el mismo navegador y evitar suplantaciones de identidad), etc,... La OWASP recomienda en su categoría OWASP-AT-007 diferentes tests a los métodos de logout para garantizar la desconexión real del servidor y evitar la posible resurrección de sesiones.

Lo que plantea Bruce está más centrado en el segundo de los casos. Aquellos en los que la sesión se queda abierta y no hay ningún control que evite que otro usuario pueda pasar por delante del PC del individuo y llevar a cabo acciones a las que no debería tener permiso, y suplantando la identidad.

La medida más típica es el autobloqueo de la sesión del sistema operativo tras un tiempo de inactividad. Esto ayuda a que el tiempo de exposición del acceso al PC sea menor. No todos los sistemas operativos traen estas opciones habilitadas por defecto. No obstante, vía red, es posible hacer secuestros de sesión (según el tipo de protocolo: un telnet, una sesión web mediante MiTM o robo de cookies, técnicas como pass-the-hash en entornos Microsoft...) de las aplicaciones que aún corren en la máquina. Algunas de ellas se pueden configurar para que hagan un logout automático de la sesión en caso de un umbral de inactividad. Lo mismo sucede a nivel de ciertos protocolos como puede ser FTP y HTTPS.

Sin embargo, hay medidas para minimizar el tiempo de exposición entre que el usuario se levanta a por café y las sesiones se bloquean. Para notificar al sistema operativo o a las aplicaciones que el usuario se ausenta existen mecanismos basados en tokens, tarjetas inteligentes, bluetooth, incluso RFID (insertado en el llavero del usuario). En definitiva basados en la proximidad.

En este tipo de proyectos hay que tener muy en cuenta que el exceso de seguridad no merma la usabilidad de las aplicaciones. Es decir, que si se afina demasiado la sensibilidad de los sensores de presencia la sesión se bloqueará con que el usuario se mueva escasos metros de su sitio, lo cuál no siempre es deseado. Lo mismo ocurrirá si cada pocos minutos hay que repetir la contraseña para las aplicaciones. Esto suele generar cabreo por parte de los mismos y terminan no utilizando estas medidas o llenando de quejas las colas de los call centers de ayuda al usuario.