Objetivo
Evaluar controles de identidad y sesión
Enfoque
Login, tokens, MFA, credenciales y recuperación
Resultado
Detectar debilidades sin abusar de cuentas reales
17.1 Introducción
La identidad es una de las superficies más importantes en ciberseguridad. Si un atacante obtiene acceso válido, muchas defensas técnicas pierden efectividad porque las acciones parecen provenir de un usuario legítimo.
En aplicaciones web, APIs y entornos corporativos, las pruebas de autenticación y sesión buscan validar si el sistema protege adecuadamente login, recuperación de cuenta, MFA, cookies, tokens, cierre de sesión, bloqueo de intentos y manejo de credenciales.
Estas pruebas deben realizarse con cuentas autorizadas, sin fuerza bruta no permitida y sin exponer credenciales reales. El objetivo es descubrir debilidades de diseño y configuración, no interrumpir usuarios.
17.2 Autenticación, autorización y sesión
Conviene separar tres conceptos que suelen confundirse:
| Concepto |
Pregunta que responde |
Ejemplo de falla |
| Autenticación |
¿Quién eres? |
Bypass de login o credenciales débiles |
| Autorización |
¿Qué puedes hacer? |
Usuario común accede a función admin |
| Sesión |
¿Cómo se mantiene tu identidad? |
Cookie reutilizable después del logout |
| MFA |
¿Qué factor adicional confirma acceso? |
Flujo alternativo permite entrar sin segundo factor |
| Credenciales |
¿Cómo se crean, protegen y rotan secretos? |
Contraseñas expuestas o sin política de rotación |
17.3 Preparación de pruebas de identidad
Antes de probar autenticación, se deben preparar cuentas, roles y datos. Esto evita usar cuentas reales o afectar usuarios productivos.
- Solicitar cuentas de laboratorio con roles definidos.
- Confirmar si se permite probar bloqueo de cuentas.
- Definir límites sobre intentos de login.
- Separar cuentas con MFA y sin MFA si corresponde.
- Contar con correos o teléfonos de prueba para recuperación.
- Evitar contraseñas reales o corporativas en evidencias.
- Registrar qué cuenta se usa en cada prueba.
Las pruebas de identidad mal coordinadas pueden bloquear usuarios, generar alertas o exponer secretos. El alcance debe ser explícito.
17.4 Pruebas del flujo de login
El login debe validar credenciales de forma segura, limitar abuso y no revelar información innecesaria.
- Verificar mensajes de error ante usuario inexistente y contraseña incorrecta.
- Revisar si existe enumeración de usuarios.
- Comprobar protección contra intentos repetidos.
- Observar si hay rate limiting por IP, cuenta o dispositivo.
- Revisar si el login usa HTTPS obligatorio.
- Verificar si las credenciales se transmiten en cuerpo seguro y no en URL.
- Comprobar que el login genera una sesión nueva y válida.
17.5 Enumeración de usuarios
La enumeración de usuarios ocurre cuando la aplicación revela si una cuenta existe. Puede ocurrir en login, registro, recuperación de contraseña, invitaciones o APIs.
| Canal |
Señal de enumeración |
Validación segura |
| Login |
Mensajes distintos por usuario válido |
Comparar cuenta de prueba existente y no existente |
| Recuperación |
Indica si envió correo o si no existe |
Usar correos de laboratorio |
| Registro |
Indica que el correo ya está registrado |
Evaluar si el mensaje expone cuentas sensibles |
| API |
Códigos o tiempos distintos |
Comparar respuestas sin automatización agresiva |
17.6 Políticas de contraseña
La política de contraseña debe equilibrar seguridad y usabilidad. Una política excesivamente compleja puede fomentar reutilización; una demasiado débil facilita ataques de credenciales.
- Longitud mínima adecuada.
- Bloqueo de contraseñas comunes o filtradas.
- Permitir frases largas.
- No imponer rotación arbitraria sin motivo.
- Evitar reglas predecibles que agregan poco valor.
- Proteger cambio de contraseña con sesión válida y, si aplica, reautenticación.
- No almacenar contraseñas en claro ni reversibles.
17.7 Protección contra fuerza bruta y credential stuffing
Las pruebas de fuerza bruta o stuffing requieren autorización explícita. En la mayoría de pentests, se validan controles con pocos intentos controlados y cuentas de laboratorio.
- Rate limiting por cuenta, IP y patrón.
- Bloqueo temporal progresivo.
- Alertas ante intentos anómalos.
- MFA en cuentas sensibles.
- Detección de contraseñas filtradas.
- Protección contra automatización.
- No revelar si la cuenta existe durante intentos fallidos.
Probar diez intentos controlados no es lo mismo que lanzar un ataque de fuerza bruta. La diferencia debe estar definida en las reglas de compromiso.
17.8 Recuperación de contraseña
El flujo de recuperación de contraseña es crítico porque permite recuperar acceso sin conocer la contraseña actual. Debe ser resistente a enumeración, reutilización de tokens y abuso de enlaces.
Aspectos a revisar:
- Mensajes genéricos ante cuentas existentes o inexistentes.
- Tokens de recuperación largos, aleatorios y de un solo uso.
- Expiración corta y razonable.
- Invalidación al usar el token.
- No incluir tokens en logs o URLs compartidas innecesariamente.
- No permitir cambiar correo o MFA durante recuperación sin controles extra.
- Notificación al usuario después del cambio.
17.9 Cambio de contraseña
El cambio de contraseña desde una sesión autenticada también debe protegerse. Si un atacante roba una sesión, el sistema no debería permitir cambios críticos sin controles adicionales.
- Requerir contraseña actual o reautenticación.
- Invalidar sesiones previas tras cambio exitoso.
- Notificar al usuario.
- Aplicar política de calidad de contraseña.
- Evitar CSRF en la acción.
- No exponer contraseñas en respuestas, logs o URLs.
17.10 Gestión de sesiones
Una sesión vincula solicitudes sucesivas con un usuario autenticado. Debe ser impredecible, protegida, renovada en eventos críticos y revocable.
| Control |
Qué revisar |
Riesgo si falla |
| Regeneración |
Cambia ID de sesión al iniciar sesión |
Session fixation |
| Expiración |
Tiempo absoluto e inactividad |
Sesiones indefinidas |
| Logout |
Invalidación real del token |
Reutilización después de cerrar sesión |
| Rotación |
Cambia ante eventos sensibles |
Abuso de token antiguo |
| Almacenamiento |
Cookie, storage o cabecera |
Exposición a XSS o fuga de tokens |
17.11 Cookies de sesión
Las cookies de sesión deben tener atributos adecuados para reducir exposición.
- Secure: solo se envía por HTTPS.
- HttpOnly: no es accesible desde JavaScript.
- SameSite: reduce riesgo de CSRF según configuración.
- Path y Domain: limitan alcance de envío.
- Expires o Max-Age: controlan persistencia.
La ausencia de un atributo no siempre tiene la misma severidad. Debe evaluarse según contexto, tipo de cookie e impacto.
17.12 Tokens JWT
Los JWT son comunes en APIs y aplicaciones modernas. Deben validarse correctamente en servidor y manejarse con cuidado en cliente.
Aspectos a revisar:
- Algoritmo esperado y rechazo de algoritmos inseguros.
- Validación de firma.
- Expiración y refresh tokens.
- Claims de rol, usuario, tenant y permisos.
- No incluir datos sensibles innecesarios en el token.
- Revocación o rotación ante eventos críticos.
- Almacenamiento en cliente y exposición a XSS.
Un JWT firmado no significa que sea seguro si contiene permisos manipulables, expiración débil o datos sensibles innecesarios.
17.13 MFA
MFA agrega un factor adicional al login. Su valor depende de cómo se implementa, dónde se exige y si existen rutas alternativas para evadirlo.
- Aplicación obligatoria en cuentas privilegiadas.
- Protección de recuperación y cambios de MFA.
- Códigos de respaldo protegidos.
- Evitar bypass por endpoints antiguos o APIs.
- Requerir MFA en acciones sensibles, no solo login.
- Revisar "recordar dispositivo" y duración de confianza.
- Monitorear cambios de factor.
17.14 Bypass de MFA
El bypass de MFA suele ocurrir por flujos alternativos o estados mal manejados, no necesariamente por romper el factor criptográficamente.
| Ruta |
Riesgo |
Prueba segura |
| Recuperación de cuenta |
Restablece acceso sin MFA |
Usar cuenta de laboratorio |
| API directa |
Endpoint acepta token previo a MFA |
Comparar llamadas antes y después del factor |
| Recordar dispositivo |
Confianza excesiva o transferible |
Revisar duración y vinculación |
| Códigos de respaldo |
Débiles, reutilizables o visibles |
Validar generación y revocación |
| Cambio de correo o teléfono |
Secuestra canal de segundo factor |
Probar con datos de laboratorio |
17.15 SSO y federación
Muchas aplicaciones delegan autenticación a proveedores de identidad mediante SAML, OAuth2 u OpenID Connect. Esto reduce exposición si está bien configurado, pero introduce riesgos de integración.
- Validación correcta de redirect_uri.
- Restricción de clientes y scopes.
- Verificación de firma y audiencia en tokens.
- Protección contra reutilización de códigos.
- Mapeo correcto de roles y grupos.
- Cierre de sesión local y federado.
- Control sobre cuentas externas o invitadas.
17.16 Gestión de credenciales
Las credenciales incluyen contraseñas, claves API, tokens, certificados, secretos de aplicación y llaves privadas. Su exposición puede tener impacto mayor que una vulnerabilidad técnica aislada.
- No almacenar secretos en código fuente.
- Usar gestores de secretos.
- Rotar credenciales expuestas o sospechosas.
- Aplicar mínimo privilegio.
- Separar secretos por entorno.
- Registrar uso anómalo.
- Evitar compartir credenciales personales entre usuarios o servicios.
17.17 Almacenamiento de contraseñas
Las contraseñas no deben almacenarse en claro ni con cifrado reversible. Deben protegerse con funciones de hash diseñadas para contraseñas, sal y parámetros adecuados.
- Usar Argon2, bcrypt, scrypt o PBKDF2 con parámetros robustos.
- Aplicar sal única por contraseña.
- No usar MD5, SHA1 o SHA256 simple para contraseñas.
- Proteger backups y dumps de base de datos.
- Limitar acceso administrativo a hashes.
- Rotar credenciales si se sospecha exposición.
17.18 Secretos en cliente y frontend
Una aplicación web no debe incluir secretos reales en JavaScript, aplicaciones móviles o archivos públicos. Todo lo que llega al cliente debe considerarse visible.
Señales de riesgo:
- Claves API en archivos JavaScript.
- Tokens estáticos en frontend.
- Credenciales en mapas fuente.
- Endpoints internos expuestos en bundles.
- Variables de entorno publicadas por error.
- Secretos compartidos entre frontend y backend.
Una clave en frontend no puede tratarse como secreta. Si necesita protección, debe estar del lado servidor.
17.19 Pruebas de cierre de sesión
El cierre de sesión debe invalidar la sesión en el servidor o revocar el token según el modelo usado. Borrar una cookie en el navegador no siempre alcanza.
- Probar si el token anterior sigue funcionando después del logout.
- Verificar cierre en varios dispositivos.
- Revisar comportamiento al cambiar contraseña.
- Comprobar revocación de refresh tokens.
- Validar expiración de sesiones inactivas.
- Confirmar que páginas sensibles no quedan en caché.
17.20 Monitoreo y alertas de identidad
La prevención no alcanza. Las organizaciones necesitan detectar abuso de credenciales y sesiones.
| Evento |
Señal |
Respuesta esperada |
| Intentos fallidos repetidos |
Posible ataque de credenciales |
Rate limiting, alerta o bloqueo temporal |
| Login desde ubicación inusual |
Riesgo de cuenta comprometida |
Verificación adicional o alerta |
| Cambio de MFA |
Posible secuestro de cuenta |
Notificación y registro de auditoría |
| Uso de token expirado |
Problema de revocación o abuso |
Rechazo y registro |
| Acceso a recurso no autorizado |
Prueba de IDOR o abuso real |
Bloqueo, alerta y trazabilidad |
17.21 Evidencia en pruebas de autenticación
La evidencia debe demostrar la debilidad sin exponer contraseñas, tokens completos o datos personales innecesarios.
- Truncar tokens, cookies y secretos.
- No incluir contraseñas en claro.
- Usar cuentas de laboratorio.
- Registrar rol, flujo y resultado.
- Mostrar diferencias de respuesta relevantes.
- Documentar cantidad de intentos si se prueba rate limiting.
- Proteger capturas con datos de sesión.
17.22 Errores frecuentes
- Probar fuerza bruta sin autorización explícita.
- Usar cuentas reales de empleados cuando existen cuentas de prueba.
- Reportar cookies sin SameSite como críticas sin analizar contexto.
- No probar recuperación de cuenta.
- Olvidar APIs o endpoints móviles en pruebas de MFA.
- Guardar tokens completos en evidencias.
- No probar revocación tras logout o cambio de contraseña.
- Confundir autenticación correcta con autorización correcta.
17.23 Flujo práctico de pruebas
Un flujo responsable para esta área puede ser:
- Confirmar cuentas, roles y límites de intentos.
- Mapear login, registro, recuperación y cambio de contraseña.
- Revisar enumeración de usuarios con datos de laboratorio.
- Validar políticas de contraseña y rate limiting.
- Probar MFA, rutas alternativas y recuperación.
- Analizar cookies, tokens, expiración y logout.
- Revisar SSO, claims, scopes y mapeo de roles si aplica.
- Buscar exposición de secretos en frontend y configuración.
- Recolectar evidencia mínima y protegida.
- Priorizar por posibilidad de acceso no autorizado.
17.24 Qué debes recordar de este tema
- La autenticación valida identidad, pero no reemplaza autorización.
- Las pruebas de credenciales deben estar explícitamente autorizadas.
- La recuperación de cuenta puede ser tan crítica como el login.
- Las sesiones deben expirar, rotarse e invalidarse correctamente.
- MFA debe proteger rutas alternativas, no solo el login principal.
- Tokens, cookies y secretos deben tratarse como evidencia sensible.
17.25 Conclusión
Las pruebas de autenticación, sesiones, MFA y credenciales evalúan la puerta de entrada a la aplicación. Una debilidad en identidad puede convertir controles posteriores en irrelevantes, especialmente si afecta cuentas privilegiadas o sesiones persistentes.
En el próximo tema pasaremos a explotación en Linux: permisos, servicios, SUID, capabilities y escalada local, donde veremos cómo analizar un sistema después de obtener acceso autorizado a un entorno de prueba.