OWASP: A07 2025 - Authentication Failures

¿Qué es Authentication Failures?

Authentication Failures agrupa fallos que permiten que un sistema reconozca como legítima una identidad que no ha sido autenticada correctamente, o que un atacante mantenga o reutilice una sesión de forma no prevista.

El objetivo es identificar rutas que permitan obtener acceso a una cuenta, reducir la seguridad del proceso de autenticación, reutilizar credenciales o sesiones, o evitar controles adicionales como MFA.

En este artículo analizamos las siguientes áreas:

Enumeración de usuarios
Ataques contra credenciales
Credenciales débiles, predeterminadas o comprometidas
Recuperación y cambio de credenciales
Autenticación multifactor (MFA)
Gestión de sesiones
Session Fixation
Tokens y credenciales de acceso
Autenticación en canales e integraciones
Almacenamiento de contraseñas

Enumeración de usuarios

Los mecanismos de autenticación y recuperación pueden revelar si una cuenta existe mediante diferencias observables en la respuesta.

Busca estas diferencias en:

• Login.
• Registro.
• Recuperación de contraseña.
• Cambio de correo.
• Invitaciones.
• APIs de autenticación.
• MFA.
• SSO.

Por ejemplo, compara una cuenta válida con otra inexistente:

Usuario válido:
"Contraseña incorrecta"

Usuario inexistente:
"El usuario no existe"

La diferencia permite confirmar qué identificadores están registrados.

También presta atención a variaciones en:

• Código HTTP.
• Tamaño de la respuesta.
• Redirecciones.
• Cabeceras.
• Tiempo de respuesta.
• Mensajes enviados por correo o SMS.

La validación debe realizarse con un número reducido de cuentas conocidas. No es necesario enumerar grandes listas para demostrar el comportamiento.

Red Team OPSEC

Evita enumeraciones masivas cuando unas pocas comparaciones controladas sean suficientes para confirmar que el sistema revela la existencia de cuentas.

Ataques contra credenciales

OWASP contempla como fallo de autenticación que la aplicación permita ataques automatizados sin controles adecuados.

Entre ellos se encuentran:

• Brute Force
• Password Spraying
• Credential Stuffing
• Variaciones de credenciales comprometidas

Brute Force

Comprueba si el sistema restringe intentos repetidos de autenticación.

Presta atención a:

• Rate limiting.
• Bloqueos temporales.
• Incremento progresivo del tiempo de respuesta.
• CAPTCHA u otros controles adaptativos.
• Alertas o cambios de comportamiento.
• Límites por cuenta, IP, sesión o dispositivo.

No es necesario encontrar una contraseña mediante fuerza bruta.

La validación consiste en demostrar que se pueden realizar múltiples intentos consecutivos sin que aparezca un control razonable.

Password Spraying

El Password Spraying utiliza un número reducido de contraseñas sobre múltiples cuentas para evitar límites aplicados únicamente por usuario.

Durante una evaluación, comprueba si los controles dependen exclusivamente del identificador de cuenta o si existen mecanismos adicionales capaces de detectar intentos distribuidos.

Red Team OPSEC

Los ataques de Password Spraying pueden bloquear múltiples cuentas y generar un impacto operativo considerable.

Utiliza exclusivamente cuentas autorizadas o una muestra mínima expresamente contemplada en el alcance.

Credential Stuffing

Credential Stuffing consiste en reutilizar combinaciones de usuario y contraseña obtenidas previamente en otros servicios.

Desde un pentest normalmente no es necesario realizar campañas extensas. El objetivo es determinar si el sistema dispone de controles capaces de reducir el abuso automatizado de credenciales válidas o comprometidas.

En ejercicios de Red Team donde este vector forme parte del escenario, deben utilizarse únicamente credenciales obtenidas o proporcionadas dentro de los límites del ejercicio.

Credenciales débiles, predeterminadas o comprometidas

Una aplicación puede presentar debilidades si permite:

• Contraseñas triviales.
• Credenciales predeterminadas.
• Credenciales conocidas públicamente.
• Contraseñas presentes en filtraciones conocidas.
• Credenciales embebidas en código o configuración.
• Cuentas administrativas creadas con valores por defecto.

Algunos ejemplos típicos son:

admin / admin
admin / password
test / test

El objetivo no es probar listas completas de contraseñas por defecto.

Si se identifica un producto o componente concreto, puede realizarse una comprobación mínima utilizando únicamente las credenciales predeterminadas documentadas para ese producto.

Credenciales hardcoded

Durante el análisis de código, JavaScript, aplicaciones cliente, repositorios o archivos de configuración, presta atención a:

username
password
api_key
client_secret
token

Una credencial incluida directamente en un cliente distribuido o recurso accesible debe considerarse potencialmente recuperable por un atacante.

La validación puede limitarse a determinar si la credencial sigue siendo válida y qué acceso proporciona, evitando realizar acciones innecesarias.

Red Team OPSEC

No conviertas la comprobación de credenciales conocidas o predeterminadas en un ataque de diccionario.

Un número reducido de intentos dirigidos suele ser suficiente.

Recuperación y cambio de credenciales

Los mecanismos de recuperación suelen representar una ruta alternativa hacia el control de una cuenta.

Comprueba:

• Forgot password.
• Cambio de contraseña.
• Recuperación mediante correo o SMS.
• Preguntas de seguridad.
• Links o tokens de recuperación.
• Códigos de un solo uso.
• Recuperación mediante soporte.

Enumeración durante recuperación

Comprueba si el sistema responde de forma diferente:

"Se ha enviado un correo de recuperación"

frente a:

"No existe ninguna cuenta con ese correo"

Esto puede permitir enumerar cuentas incluso cuando el login utiliza mensajes genéricos.

Tokens de recuperación

Analiza si los tokens:

• Son suficientemente impredecibles.
• Expiran.
• Son de un solo uso.
• Quedan invalidados tras cambiar la contraseña.
• Están asociados al usuario y operación correctos.
• Pueden reutilizarse.
• Aparecen en ubicaciones inseguras.

Una comprobación sencilla consiste en completar una recuperación con una cuenta controlada e intentar reutilizar el mismo token.

Cambio de contraseña

Comprueba si una sesión autenticada puede cambiar la contraseña sin verificar adecuadamente la operación.

Dependiendo del nivel de riesgo, puede esperarse:

• Contraseña actual.
• MFA.
• Reautenticación.
• Confirmación mediante otro canal.

También comprueba si cambiar una contraseña invalida sesiones o tokens existentes cuando ese comportamiento sea necesario para impedir que un atacante mantenga acceso.

Preguntas de seguridad

Los mecanismos basados en información personal o respuestas de conocimiento suelen proporcionar una autenticación considerablemente más débil que la contraseña o MFA que pretenden recuperar.

Si existe este mecanismo, analiza si puede convertirse en el camino más sencillo para tomar control de una cuenta.

Red Team OPSEC

Realiza pruebas de recuperación únicamente sobre cuentas controladas. Evita provocar correos, SMS o cambios de credenciales sobre usuarios reales.

Autenticación multifactor (MFA)

OWASP contempla como fallo la ausencia de MFA cuando resulta necesario, su implementación ineficaz o la existencia de mecanismos de fallback más débiles.

Durante la evaluación identifica:

Login con MFA
Activación de MFA
Desactivación de MFA
Cambio de dispositivo
Códigos de recuperación
Remember this device
Recuperación de cuenta
SSO

Bypass del flujo

Comprueba si es posible acceder directamente a una ruta posterior a la verificación.

Por ejemplo:

/login
/mfa
/dashboard

Después de completar únicamente el primer factor, solicita directamente un recurso autenticado.

La aplicación debe comprobar el estado de MFA en backend y no únicamente utilizar la página /mfa como barrera de navegación.

Endpoints alternativos

Compara si diferentes interfaces aplican los mismos requisitos:

Web
API
Aplicación móvil
Endpoints legacy

Una aplicación puede exigir MFA en el frontend principal pero aceptar una autenticación equivalente mediante otro endpoint.

Códigos MFA

Comprueba de forma limitada:

• Longitud y espacio de búsqueda.
• Caducidad.
• Reutilización.
• Número de intentos.
• Asociación con la sesión o usuario.
• Validez simultánea de varios códigos.

No es necesario adivinar un código válido para confirmar que no existen restricciones de intentos.

Fallbacks

Presta especial atención a mecanismos como:

No tengo acceso a mi dispositivo
Usar código de recuperación
Enviar SMS
Contactar con soporte
Recordar dispositivo

La fortaleza global del MFA queda limitada por la ruta alternativa más débil que permita obtener el mismo nivel de acceso.

Red Team OPSEC

Limita las pruebas de códigos MFA y recuperación para evitar bloqueos, consumo de códigos legítimos o generación masiva de SMS y notificaciones.

Gestión de sesiones

Una autenticación correcta puede quedar comprometida por una gestión de sesión deficiente.

Durante la evaluación analiza:

• Dónde se almacena el identificador.
• Si cambia después del login.
• Qué ocurre al cerrar sesión.
• Expiración por inactividad.
• Expiración absoluta.
• Invalidación tras eventos sensibles.
• Sesiones simultáneas.
• Reutilización de tokens.

Exposición del identificador de sesión

Los identificadores de sesión no deberían aparecer en ubicaciones que faciliten su exposición.

Presta atención a:

https://target.com/account?session=abc123

Campos ocultos:

<input type="hidden" name="session" value="abc123">

O cualquier mecanismo donde el identificador pueda terminar en:

• Historial del navegador.
• Logs.
• Cabecera Referer.
• Sistemas intermedios.
• Analítica.
• URLs compartidas.

Las cookies de sesión deberían utilizar atributos adecuados al contexto, como Secure, HttpOnly y una política SameSite coherente con el funcionamiento de la aplicación.

Logout

Obtén un recurso autenticado, cierra sesión y repite la petición utilizando la sesión anterior.

Si el mismo identificador continúa proporcionando acceso, la operación de logout no está invalidando correctamente la sesión.

Expiración

Comprueba si las sesiones disponen de:

• Idle timeout.
• Absolute timeout.

No es necesario esperar periodos extremadamente largos durante una evaluación. Si los valores pueden determinarse mediante configuración, documentación o comportamiento controlado, evita pruebas innecesariamente prolongadas.

Invalidación después de cambios sensibles

Comprueba qué ocurre con sesiones existentes cuando:

• Se cambia la contraseña.
• Se desactiva la cuenta.
• Se modifica MFA.
• Se revocan dispositivos.
• Un administrador fuerza el cierre de sesión.

El impacto depende de si una sesión previamente comprometida puede mantenerse activa a pesar de una acción destinada a recuperar la seguridad de la cuenta.

Session Fixation

Session Fixation ocurre cuando una aplicación mantiene el mismo identificador de sesión antes y después de autenticarse.

Obtén una sesión sin autenticar:

Set-Cookie: session=ABC123

Realiza el login y observa el identificador posterior.

Una implementación segura debería generar un nuevo identificador de sesión después de autenticar correctamente al usuario:

Antes:   ABC123
Después: X9F82K...

Si el identificador permanece estable, analiza si una sesión conocida previamente por otra parte podría convertirse posteriormente en una sesión autenticada.

La existencia de una cookie persistente antes y después del login no confirma automáticamente Session Fixation. Debe comprobarse que el identificador que representa la sesión autenticada realmente se reutiliza.

Tokens y credenciales de acceso

Las aplicaciones modernas pueden utilizar:

• JWT.
• OAuth access tokens.
• ID tokens.
• SSO tokens.
• API tokens.
• Tokens propietarios.

No basta con verificar que el token posee una firma válida.

El servicio debe comprobar que la credencial fue emitida para el contexto en el que está siendo utilizada.

Presta atención a:

issuer (iss)
audience (aud)
scope
expiration
token type

Audience e Issuer

Un servicio que acepta un token emitido para otra aplicación o audiencia puede permitir reutilizar credenciales fuera de su contexto previsto.

Cuando dispongas de varios servicios o clientes controlados, comprueba si un token destinado a uno de ellos es aceptado por otro.

Scope

Comprueba si el backend aplica realmente los scopes asociados al token.

Por ejemplo, un token:

scope: profile:read

no debería permitir ejecutar una operación que requiera:

profile:write

El hallazgo se confirma cuando una credencial válida puede utilizarse fuera del propósito o alcance para el que fue emitida.

Revocación

Cuando exista una función para revocar una sesión o token, valida con una cuenta controlada que la credencial deje de funcionar después de la revocación.

Red Team OPSEC

Evita probar tokens obtenidos de usuarios reales sobre múltiples servicios. Siempre que sea posible utiliza credenciales y sesiones de cuentas controladas para validar alcance, revocación y reutilización.

Autenticación en canales e integraciones

OWASP A07 también incluye debilidades relacionadas con la verificación de la identidad de los extremos de una comunicación.

Este tipo de problema puede aparecer cuando un sistema confía incorrectamente en:

• Certificados.
• Hostnames.
• Origen de una conexión.
• Cabeceras como Referer.
• Dirección de red.
• Información supuestamente inmutable.
• Canales internos.

Desde Red Team, presta especial atención cuando una aplicación confía en una propiedad del canal para decidir si una petición está autenticada o autorizada.

Certificados

En integraciones que utilizan certificados, comprueba conceptualmente que el cliente o servidor valide:

• Cadena de confianza.
• Hostname esperado.
• Caducidad.
• Identidad del extremo.

No es necesario realizar una auditoría completa de PKI salvo que la infraestructura forme parte del alcance.

El interés ofensivo aparece cuando una validación incorrecta permite suplantar uno de los extremos o redirigir una comunicación hacia infraestructura controlada.

Datos utilizados como autenticación

Cabeceras como:

Referer:
X-Forwarded-For:
X-Internal-User:

O atributos derivados de la red no deberían tratarse como prueba de identidad si pueden ser manipulados desde un contexto menos confiable.

Modifica de forma controlada estos valores y comprueba si afectan a decisiones de autenticación.

Almacenamiento de contraseñas

OWASP incluye dentro de Authentication Failures los casos donde las contraseñas se almacenan en texto claro, cifradas de forma reversible o mediante funciones de hash débiles.

La validación técnica de este problema se desarrolla principalmente en: A04 2025 - Cryptographic Failures

Desde el punto de vista de autenticación, el impacto principal es que una exposición del almacén de credenciales puede proporcionar directamente contraseñas reutilizables o facilitar su recuperación.