Sesión de usuarios en aplicaciones web

Al referirse al manejo de sesiones de usuario suele pensarse únicamente en el proceso de capturar el nombre de usuario (username) y su contraseña a través de una página de inicio de sesión (login), pero se omiten otras consideraciones que no son menos importantes al momento de crear un sistema estable y robusto.

Imagen de Mohamed Hassan provista por Pixabay

A continuación enumero los que considero son factores a considerar para un desarrollo de estos, sin que eso signifique que sea un listado absoluto, ni más faltaba. Pueden haber elementos adicionales a incluir o algunos que podamos no requerir para nuestro desarrollo particular, pero que cuando menos deberían evaluarse para evitar después pasar un mal trago.

Sin más preámbulos, comencemos:

1. ¿Qué elemento se usará para autenticar el usuario en su ingreso al sistema?

• Correo electrónico.
• Nombre de usuario.
• Documento de identidad (Ej. cédula de ciudadanía, número de pasaporte).
• Usando el API de un tercero (Google, Facebook).
• Otro.
• Varios o todos los anteriores? (quién dijo “miedo”, ¿ah?)

2. Para el ingreso de la contraseña durante el inicio de sesión:

• ¿Se enviará la contraseña sin cifrar o codificada usando md5 (no recomendado ya que actualmente este método se considera como obsoleto y poco seguro), sha256 o algún otro método de codificación de una vía?
• No se usará contraseña, se enviará un código SMS al celular y/o correo electrónico del usuario para completar el proceso de autenticación.

3. Del lado administrativo, tener en cuenta para la gestión de contraseñas la implementación de:

• ¿Cómo se guardará la contraseña en base de datos? (sugerencia: Evitar siempre guardar la contraseña real en texto plano sin codificar).
• Políticas de seguridad para el uso de contraseñas? (forzar longitud mínima y/o máxima, uso de mayúsculas, números, caracteres especiales, etc.).
• Proceso de recuperación en caso de olvido por parte del usuario (usualmente implica el cambio de la contraseña anterior previa validación de la identidad del usuario, usualmente mediante envío de código SMS al celular y/o correo electrónico).
• Permitir el cambio de la contraseña por parte del usuario.
• Forzar el cambio de contraseña específicamente a un usuario, manualmente requerido por el administrador del sistema.
• Forzar el cambio de contraseña a todos los usuarios del sistema (por Ej. cuando se deba cambiar el algoritmo de encripción de contraseñas o el método de registro al sistema).
• Forzar el cambio automático de contraseña por política de seguridad (Ej. cambiarla cada 30 días).

4. ¿Cómo se controla la duración de la sesión del usuario?

• Tiempo finito, luego de vencido se da cierre a la sesión actual y se forza su reingreso.
• Terminar la sesión por no actividad (Ej. el han pasado 10 minutos sin hacer click en algún enlace del sistema).
• Terminar la sesión automáticamente cuando se cierre la ventana del navegador (requiere control particular sobre las cookies usadas).
• Tiempo infinito, es decir, la sesión no termina a menos que el usuario realice el cierre manualmente (o se limpien las cookies de sesión en el navegador). Esta opción puede ser en algunos casos activada manualmente por el usuario desde el formulario de inicio de sesión.

5. ¿Qué datos complementarios mínimos se requieren para cada usuario? (datos no dependientes de la aplicación web particular).

• Nombre real completo.
• Nombres y apellidos por separado.
• Correo electrónico.
• Nombre de usuario (si aplica).

6. Algunas consideraciones de seguridad a resolver:

• ¿Puede el mismo usuario iniciar sesiones paralelas en el mismo navegador?
• ¿Puede el mismo usuario iniciar sesiones paralelas en diferentes navegadores?
• ¿Cada sesión iniciada cierra automáticamente cualquier sesión abierta previamente?
• ¿Debe reportar por correo el inicio de cada sesión paralela?
• ¿Debe reportar por correo cada inicio de sesión?

7. Algunas estadísticas sugeridas para control de los ingresos al sistema:

• Al menos la fecha del último ingreso, pero se sugiere registrar cada ingreso y salida (o cierre).
• Fecha, IP (opcional), tipo de registro y navegador (opcional) usado al iniciar sesión.
• Fecha y causa del cierre de sesión (manual, automático).
• Fecha, IP (opcional) y causa del cambio de contraseña (manual, automático, etc.).

8. ¿Esta solución se usará para un sistema monoinstancia o de múltiples instancias cliente?

• El usuario será compartido con varias aplicaciones web, cada una con su propia base de datos.
• El usuario será para un único cliente en un sistema con diferentes clientes, cada uno con su propia base de datos y diferente manera de ingresar la contraseña.
• Una combinación de las dos anteriores (un multiverso de la locura en si mismo).

Ahora ya tenemos una idea más completa de todos los posibles condicionales involucrados en la implementación de un módulo de gestión de usuarios y podemos realizar un mejor estimado del tiempo y el esfuerzo que su desarrollo habrá de tomar.

Si te gustó este contenido y te ha resultado útil, si tienes alguna observación o consideras que requiere alguna corrección, por favor házmelo saber en los comentarios.

Puedes encontrar una versión extendida de este artículo en mi blog de desarrollador.