Skip to main content
Critical

Autenticación Rota

CategoríaAutenticación y AccesoOWASPA07:2021 – Fallos de Identificación y AutenticaciónPrimera aparición2004Tiempo de lectura10 minVerificado2026-03-11
DEFINICIÓN

La autenticación rota se refiere a debilidades en los mecanismos de autenticación de una aplicación que permiten a los atacantes comprometer contraseñas, tokens de sesión o claves de identidad, o explotar fallos de implementación para asumir la identidad de otros usuarios de forma temporal o permanente. Abarca una amplia gama de fallos, incluyendo políticas de credenciales débiles, gestión insegura de sesiones, exposición de credenciales y ausencia de autenticación multifactor.

Cómo Funciona Autenticación Rota

La autenticación rota explota fallos fundamentales en cómo las aplicaciones verifican la identidad del usuario y gestionan las sesiones autenticadas. A diferencia de ataques dirigidos como la fuerza bruta o el credential stuffing, la autenticación rota describe debilidades sistémicas en la arquitectura de autenticación — las decisiones de diseño y errores de implementación que hacen posibles esos ataques dirigidos. Un solo fallo de autenticación rota puede socavar todo el modelo de seguridad de una aplicación, porque la autenticación es la puerta de entrada a toda la funcionalidad autorizada.

1

Reconocimiento y descubrimiento de endpoints

El atacante mapea la superficie de autenticación: páginas de inicio de sesión, formularios de registro, flujos de restablecimiento de contraseña, endpoints de autenticación de API, callbacks de OAuth, integraciones SSO y mecanismos de gestión de sesiones. Identifican qué métodos de autenticación son soportados (contraseñas, MFA, biometría, claves de API) y buscan endpoints heredados o deprecados que puedan tener protecciones más débiles.

2

Identificar debilidades de autenticación

El atacante prueba fallos comunes: ¿La aplicación permite contraseñas débiles (ej., 'password123')? ¿Existen mecanismos de bloqueo de cuenta después de intentos fallidos? ¿El flujo de restablecimiento de contraseña filtra información o usa tokens predecibles? ¿Los tokens de sesión se generan con suficiente entropía? ¿Las credenciales se transmiten por canales sin cifrar? ¿La página de inicio de sesión revela si un nombre de usuario existe mediante diferentes mensajes de error?

3

Explotar fallos de gestión de credenciales

Si la aplicación usa hashing de contraseñas débil (MD5, SHA1 sin salt), almacena credenciales en texto plano, o las transmite sin TLS, el atacante puede interceptar o descifrar contraseñas. Se prueban credenciales por defecto en interfaces de administración (admin/admin, root/toor). Los tokens de restablecimiento de contraseña se analizan para detectar predictibilidad — tokens secuenciales, basados en timestamps, o con aleatoriedad insuficiente pueden ser falsificados.

4

Explotar debilidades de gestión de sesiones

Se analizan los tokens de sesión para detectar predictibilidad y gestión adecuada del ciclo de vida. Las debilidades incluyen: IDs de sesión en URLs (visibles en encabezados referrer y logs), tokens que no se rotan después del inicio de sesión (fijación de sesión), sesiones que no expiran o tienen tiempos de espera excesivamente largos, tokens transmitidos sin las flags Secure/HttpOnly, y sesiones no invalidadas al cerrar sesión o cambiar la contraseña.

5

Lograr acceso no autorizado

El atacante aprovecha las debilidades descubiertas para obtener acceso: falsificando tokens de sesión, reproduciendo credenciales interceptadas, explotando flujos de restablecimiento de contraseña, o secuestrando sesiones mediante XSS combinado con la ausencia de flags HttpOnly. Una vez autenticado como otro usuario, accede a datos sensibles, realiza operaciones privilegiadas o establece acceso persistente mediante cuentas backdoor.

Ejemplos Reales

2022

Brecha de sistemas internos de Uber

Un atacante de 18 años obtuvo acceso a los sistemas internos de Uber comprando credenciales robadas de la dark web y luego usando ingeniería social para que un empleado aprobara una notificación push de MFA. El atacante accedió al Slack de Uber, Google Workspace, consola de AWS, panel de bug bounty de HackerOne y herramientas financieras internas. El incidente demostró cómo la autenticación rota se extiende más allá de las contraseñas — los ataques de fatiga de MFA explotan el elemento humano en los flujos de autenticación.

2019

Exposición de credenciales en Citrix ADC

Una vulnerabilidad de path traversal en Citrix Application Delivery Controller (CVE-2019-19781) permitió a atacantes no autenticados acceder a archivos de credenciales y tokens de sesión. La vulnerabilidad afectó a más de 80,000 organizaciones en 158 países. Los atacantes usaron las credenciales expuestas para acceder a redes internas, demostrando cómo los fallos de almacenamiento de credenciales se propagan en un compromiso total de la infraestructura.

2021

SSRF de Microsoft Exchange a bypass de autenticación

La cadena de vulnerabilidades ProxyLogon (CVE-2021-26855) en Microsoft Exchange Server permitió a los atacantes eludir la autenticación por completo usando server-side request forgery. Los atacantes suplantaban al servidor Exchange para autenticarse como cualquier usuario sin credenciales, accedían al correo electrónico, instalaban web shells y exfiltraban datos. Más de 250,000 servidores fueron comprometidos en todo el mundo, afectando a agencias gubernamentales, contratistas de defensa e infraestructura crítica.

Impacto y Evaluación de Riesgo

La autenticación rota se clasifica consistentemente entre las vulnerabilidades de aplicaciones web más críticas porque socava directamente el límite de seguridad fundamental entre usuarios autenticados y no autenticados. La explotación exitosa otorga a los atacantes el mismo acceso que los usuarios legítimos — o administradores — sin activar los controles de autorización. El impacto incluye toma masiva de cuentas, acceso no autorizado a datos sensibles, fraude financiero, robo de identidad, violaciones regulatorias (GDPR, HIPAA, PCI DSS) y destrucción reputacional. En entornos empresariales, la autenticación comprometida puede proporcionar el punto de entrada inicial para amenazas persistentes avanzadas (APTs), permitiendo movimiento lateral, escalación de privilegios y exfiltración de datos a largo plazo. El Informe de Investigaciones de Brechas de Datos de Verizon de 2023 encontró que las credenciales robadas estuvieron involucradas en el 49% de todas las brechas de datos.

Cómo Detectar Autenticación Rota

Monitorear los sistemas de autenticación en busca de patrones anómalos: altas tasas de intentos de inicio de sesión fallidos, inicios de sesión exitosos desde ubicaciones geográficas o direcciones IP inusuales, sesiones activas simultáneas desde diferentes ubicaciones, inicios de sesión fuera del horario laboral normal, y solicitudes de restablecimiento de contraseña para cuentas sin cambios posteriores de contraseña. Implementar detección de anomalías de sesión para identificar tokens robados o falsificados — cambios repentinos en user agent, dirección IP o huella digital del dispositivo a mitad de sesión indican secuestro de sesión. Registrar todos los eventos de autenticación con metadatos contextuales (IP, user agent, ID de dispositivo, geolocalización) e implementar alertas en tiempo real sobre patrones de autenticación de alto riesgo. Realizar auditorías regulares del almacenamiento de credenciales para asegurar algoritmos de hashing y uso de salt adecuados. Probar los flujos de restablecimiento de contraseña para detectar fugas de información y predictibilidad de tokens.

Cómo Prevenir Autenticación Rota

Implementar autenticación multifactor (MFA) para todas las cuentas de usuario, especialmente el acceso administrativo — MFA mitiga la mayoría de los ataques basados en credenciales. Aplicar políticas de contraseñas fuertes: mínimo 12 caracteres, verificar contra listas de brechas conocidas (HaveIBeenPwned) y prevenir patrones de contraseñas comunes. Usar bcrypt, scrypt o Argon2id para el hashing de contraseñas con factores de trabajo apropiados. Implementar gestión de sesiones adecuada: generar tokens de sesión criptográficamente aleatorios (mínimo 128 bits de entropía), rotar tokens después de la autenticación, establecer tiempos de expiración apropiados e invalidar sesiones al cerrar sesión y cambiar contraseña. Establecer los atributos Secure, HttpOnly y SameSite en las cookies de sesión. Implementar bloqueo de cuenta con retroceso exponencial después de intentos fallidos. Usar flujos seguros de restablecimiento de contraseña con tokens de un solo uso, limitados en tiempo y criptográficamente aleatorios. Implementar limitación de velocidad en todos los endpoints de autenticación. Las pruebas de seguridad regulares deben incluir casos de prueba específicos de autenticación que cubran gestión de credenciales, manejo de sesiones y escenarios de bypass de autenticación.

Ejemplos de Código

Vulnerable: Weak session management
import hashlib
import time

# VULNERABLE: Predictable session token generation
def create_session_vulnerable(user_id):
# Token based on timestamp + user_id — predictable!
token = hashlib.md5(f"{time.time()}{user_id}".encode()).hexdigest()
return token

# VULNERABLE: Session doesn't expire, no rotation
sessions = {}

def login_vulnerable(username, password):
user = db.query("SELECT * FROM users WHERE username = %s", (username,))
# Weak: plain comparison, no hashing
if user and user.password == password:
token = create_session_vulnerable(user.id)
sessions[token] = {'user_id': user.id} # Never expires!
return token
return None
Secure: Robust authentication implementation
import secrets
import bcrypt
from datetime import datetime, timedelta

SESSION_TIMEOUT = timedelta(hours=1)
MAX_FAILED_ATTEMPTS = 5
LOCKOUT_DURATION = timedelta(minutes=15)

def hash_password(password):
"""Hash password with bcrypt (work factor 12)"""
return bcrypt.hashpw(password.encode(), bcrypt.gensalt(rounds=12))

def verify_password(password, hashed):
"""Constant-time password verification"""
return bcrypt.checkpw(password.encode(), hashed)

def create_session_secure(user_id):
"""Generate cryptographically random session token"""
token = secrets.token_urlsafe(32) # 256 bits of entropy
session_store.set(token, {
'user_id': user_id,
'created_at': datetime.utcnow(),
'last_activity': datetime.utcnow(),
'ip': request.remote_addr,
'user_agent': request.headers.get('User-Agent')
}, ex=int(SESSION_TIMEOUT.total_seconds()))
return token

def login_secure(username, password):
"""Secure login with rate limiting and session rotation"""
# Check account lockout
attempts = get_failed_attempts(username)
if attempts >= MAX_FAILED_ATTEMPTS:
lockout_until = get_lockout_time(username)
if datetime.utcnow() < lockout_until:
raise AuthError('Account temporarily locked')

user = db.query("SELECT * FROM users WHERE username = %s", (username,))

# Constant-time response whether user exists or not
if not user or not verify_password(password, user.password_hash):
increment_failed_attempts(username)
# Generic message — don't reveal if username exists
raise AuthError('Invalid username or password')

# Reset failed attempts on success
reset_failed_attempts(username)

# Invalidate any existing sessions (prevent session fixation)
invalidate_user_sessions(user.id)

# Generate new session token
token = create_session_secure(user.id)

# Audit log
log_auth_event('login_success', user.id, request.remote_addr)

return token
Secure: Session cookie configuration (Express.js)
const session = require('express-session');
const RedisStore = require('connect-redis').default;
const crypto = require('crypto');

app.use(session({
store: new RedisStore({ client: redisClient }),

// Cryptographically random secret
secret: process.env.SESSION_SECRET,

// Session configuration
name: '__Host-sid', // __Host- prefix enforces Secure + no Domain
resave: false,
saveUninitialized: false,

cookie: {
secure: true, // HTTPS only
httpOnly: true, // No JavaScript access
sameSite: 'lax', // CSRF protection
maxAge: 3600000, // 1 hour expiration
path: '/',
},

// Generate secure session IDs
genid: () => crypto.randomBytes(32).toString('hex'),

// Rolling expiration — extends on activity
rolling: true,
}));

// Rotate session ID after authentication
app.post('/login', async (req, res) => {
const user = await authenticate(req.body);
if (!user) return res.status(401).json({ error: 'Invalid credentials' });

// Regenerate session to prevent fixation
req.session.regenerate((err) => {
if (err) return res.status(500).json({ error: 'Session error' });
req.session.userId = user.id;
req.session.loginTime = Date.now();
res.json({ success: true });
});
});

// Proper logout — destroy session server-side
app.post('/logout', (req, res) => {
req.session.destroy((err) => {
res.clearCookie('__Host-sid');
res.json({ success: true });
});
});

Fortalece tus defensas contra Autenticación Rota con PowerWAF.

Seguridad integral para aplicaciones web con WAF, rate limiting y monitoreo de amenazas en tiempo real.

Los cupos del plan gratuito son limitados

Preguntas Frecuentes

La autenticación rota se ocupa de verificar quién es un usuario — fallos en el inicio de sesión, gestión de sesiones y manejo de credenciales. El control de acceso roto se ocupa de lo que un usuario autenticado tiene permitido hacer — fallos en las verificaciones de autorización, aplicación de privilegios y políticas de acceso a recursos. La autenticación responde '¿Eres quien dices ser?' mientras que el control de acceso responde '¿Tienes permiso para hacer esto?' Ambos son críticos, pero la autenticación rota a menudo es más severa porque puede eludir todos los controles de acceso al suplantar a un usuario privilegiado.
MFA reduce drásticamente el riesgo pero no lo elimina por completo. Los ataques sofisticados pueden eludir MFA mediante: proxies de phishing en tiempo real (herramientas como Evilginx2 que interceptan tokens MFA), ataques de fatiga de MFA (enviar notificaciones push repetidamente hasta que el usuario apruebe), SIM swapping para MFA basado en SMS, ingeniería social al personal de soporte para restablecer MFA, y explotar tokens de sesión después de completar MFA. MFA resistente al phishing (claves de hardware FIDO2/WebAuthn) proporciona la protección más fuerte.
Las contraseñas deben hashearse usando funciones unidireccionales adaptativas diseñadas para el almacenamiento de contraseñas: Argon2id (recomendado por OWASP), bcrypt (ampliamente soportado) o scrypt. Nunca use algoritmos de hashing rápidos (MD5, SHA-1, SHA-256) incluso con salts — son demasiado rápidos para el hashing de contraseñas y pueden descifrarse a miles de millones de intentos por segundo con GPUs. Use salts aleatorios únicos por contraseña (manejado automáticamente por bcrypt/Argon2id). Establezca factores de costo apropiados: factor de trabajo de bcrypt mayor o igual a 10, Argon2id con al menos 19 MiB de memoria y al menos 2 iteraciones.
Los tokens de sesión seguros deben ser: generados usando un generador de números aleatorios criptográficamente seguro (CSPRNG) con al menos 128 bits de entropía, transmitidos solo por HTTPS (flag Secure), inaccesibles para JavaScript (flag HttpOnly), restringidos a solicitudes del mismo sitio (flag SameSite), rotados después de cambios en el nivel de autenticación, expirados después de un tiempo de inactividad razonable, e invalidados del lado del servidor al cerrar sesión. Evite exponer tokens en URLs, logs o mensajes de error.
Un WAF proporciona protección limitada contra la autenticación rota. Puede detectar y bloquear intentos de fuerza bruta, patrones de credential stuffing y algunas técnicas de manipulación de sesiones. Sin embargo, la autenticación rota es fundamentalmente un problema de diseño de la aplicación — políticas de contraseñas débiles, gestión insegura de sesiones, ausencia de MFA y fallos de almacenamiento de credenciales deben corregirse en el código de la aplicación. Un WAF es una capa de defensa valiosa pero no puede compensar debilidades arquitectónicas de autenticación.