Tema 8
La autenticación decide quién puede entrar al sistema y bajo qué condiciones. Si este proceso falla, casi todos los demás controles pierden valor. Diseñar un login seguro no consiste solo en pedir usuario y contraseña, sino en proteger identidad, sesión, recuperación de cuenta y factores adicionales de verificación.
En la mayoría de las aplicaciones web, la cuenta del usuario es la puerta de entrada a datos, funciones y operaciones sensibles. Si un atacante consigue autenticarse como otra persona, puede actuar con sus permisos sin necesidad de explotar otras vulnerabilidades más complejas.
Por eso la autenticación es uno de los pilares más importantes de la seguridad web. Abarca no solo el formulario de login, sino también el registro, el almacenamiento de credenciales, la recuperación de cuenta, el cambio de contraseña, la segunda verificación y la gestión de intentos fallidos.
Una autenticación débil no afecta solo a un usuario. Puede comprometer la reputación del sistema, habilitar fraude y convertirse en la base de incidentes más amplios.
Antes de profundizar, conviene separar tres conceptos que suelen mezclarse:
Este tema se enfoca principalmente en autenticación, pero en la práctica siempre se relaciona con cómo se mantiene la sesión y cómo se aplican permisos luego del login.
Un sistema de autenticación bien diseñado debería cumplir varios objetivos:
Aunque existen métodos modernos de autenticación, la contraseña sigue siendo el factor más extendido en aplicaciones web. El problema es que también es uno de los más abusados: puede ser adivinada, reutilizada, filtrada, robada por phishing o capturada en dispositivos comprometidos.
Esto obliga a pensar no solo en cómo se define una contraseña, sino en cómo se almacena, cómo se renueva, cómo se recupera la cuenta y cómo se combina con factores adicionales.
Una buena política de contraseñas busca equilibrio entre seguridad real y fricción aceptable. Algunas buenas prácticas suelen incluir:
Muchas políticas antiguas empeoraban la experiencia sin mejorar demasiado la seguridad. Hoy se valora más longitud, unicidad y control frente a contraseñas comprometidas.
Una aplicación nunca debería guardar contraseñas en texto plano. Si la base de datos se filtra, eso expone directamente a los usuarios y además potencia ataques por reutilización en otros servicios.
El almacenamiento correcto implica aplicar funciones de hash diseñadas específicamente para contraseñas, con salt y costo adecuado. La meta es que incluso ante una filtración, recuperar las contraseñas reales sea costoso y lento.
Desde la seguridad práctica, esto significa:
La seguridad de autenticación empieza incluso antes del primer login. En el registro conviene pensar en:
Un flujo de registro mal diseñado puede facilitar spam, cuentas falsas, enumeración o posteriores abusos de recuperación.
Una parte importante de la autenticación segura consiste en resistir ataques automáticos. Los más comunes son:
Para mitigar estos ataques se usan medidas como limitación de intentos, análisis de contexto, detección de comportamiento anómalo, MFA y verificación de contraseñas contra listas comprometidas.
Un detalle aparentemente menor puede tener mucho impacto: cómo responde la aplicación cuando el login falla. Si el sistema distingue claramente entre "usuario inexistente" y "contraseña incorrecta", ayuda al atacante a descubrir cuentas válidas.
Por eso suele recomendarse usar mensajes de error genéricos en autenticación y recuperación, evitando dar señales innecesarias sobre qué identificadores existen realmente.
Muchos sistemas tienen un login razonablemente seguro, pero una recuperación de cuenta débil. Eso es crítico porque un atacante no siempre necesita romper la contraseña si puede resetearla fácilmente.
Un flujo de recuperación seguro debería:
Cambiar una contraseña, desactivar MFA o modificar datos de recuperación son acciones de alto impacto. No deberían depender solo de una sesión antigua y silenciosa. En muchos casos es recomendable reautenticar al usuario o pedir una confirmación adicional antes de permitir esos cambios.
Esto reduce impacto de secuestro de sesión, equipos compartidos o sesiones abiertas por descuido.
MFA, o autenticación multifactor, agrega uno o más factores adicionales además de la contraseña. La idea es simple: si la contraseña se filtra o es robada, el atacante todavía necesita otra prueba para entrar.
Los factores suelen agruparse en:
| Método | Ventaja | Consideración de seguridad |
|---|---|---|
| App autenticadora | Amplio uso y buena seguridad práctica | Requiere proteger el dispositivo y el backup del secreto |
| Token físico | Muy resistente frente a phishing avanzado | Mayor costo y logística |
| SMS | Fácil de adoptar | Más débil frente a ciertos abusos del canal telefónico |
| Push al dispositivo | Cómodo para el usuario | Debe evitar fatiga o aprobaciones automáticas |
Aunque MFA reduce enormemente el riesgo de toma de cuentas, no elimina todos los ataques. Puede verse afectado por phishing en tiempo real, ingeniería social, robo del dispositivo, malware local o errores de implementación.
Por eso no debe usarse como excusa para descuidar contraseñas, sesiones, recuperación de cuenta o monitoreo. Es una capa poderosa, no una solución única.
Algunas aplicaciones ajustan el nivel de verificación según señales de riesgo, por ejemplo ubicación inusual, dispositivo nuevo, horario atípico o comportamiento sospechoso. Esto se conoce como autenticación adaptativa o basada en riesgo.
Bien implementada, permite equilibrar seguridad y experiencia, pidiendo controles adicionales cuando realmente cambia el contexto.
Muchas aplicaciones modernas delegan autenticación en proveedores externos mediante SSO o identidad federada. Esto puede mejorar seguridad y experiencia si se implementa correctamente, pero también concentra riesgo en el proveedor de identidad y en los flujos de integración.
Delegar autenticación no elimina la responsabilidad del sistema. La aplicación sigue necesitando validar tokens, proteger sesiones y manejar correctamente los permisos locales.
Imaginemos un portal donde el login exige usuario y contraseña, pero el reset de contraseña solo depende de conocer el email y usar un enlace sin expiración fuerte. Aunque el formulario principal esté razonablemente protegido, un atacante podría concentrarse en el flujo de recuperación y tomar la cuenta por allí.
Este ejemplo muestra por qué la autenticación debe analizarse como un sistema completo y no como una pantalla aislada.
Una estrategia madura de autenticación suele combinar varias capas:
La autenticación segura es una de las defensas más rentables de una aplicación web porque protege directamente el punto donde identidad, datos y permisos se encuentran. Si este sistema está bien diseñado, muchas campañas automáticas, fraudes y tomas de cuenta pierden gran parte de su eficacia.
En el próximo tema avanzaremos sobre autorización, control de acceso y prevención de IDOR, es decir, qué puede hacer realmente un usuario una vez que logró autenticarse.