El flujo de restablecimiento de contraseña es una de las rutas más atacadas de cualquier sistema de autenticación. Los atacantes saben que, si pueden disparar un correo de restablecimiento a una dirección que controlan, reproducir un enlace de restablecimiento filtrado o entrar en el formulario de cambio con una sesión robada, eluden por completo todas las defensas del momento del inicio de sesión que ofrece la plataforma.
Muchos gateways ven el restablecimiento como algo añadido después: enlaces de restablecimiento de larga vida, direcciones de destinatario visibles a la vista en la UI, formularios de cambio de contraseña sin CSRF y ausencia de auditoría sobre quién restableció qué y cuándo. Cada uno es un pequeño hueco; juntos forman una puerta lateral paralela al muro de MFA de la puerta principal.
El otro extremo — mantener las operaciones de contraseña engorrosas y solo accesibles al administrador — produce desbordamientos de la línea de soporte, contraseñas de administrador compartidas en notas adhesivas y usuarios que nunca cambian sus credenciales porque el proceso es difícil.
Las operaciones de contraseña deben ser de autoservicio, seguras y auditadas de extremo a extremo — el mismo motor que defiende el inicio de sesión debe defender también el cambio, el olvido y el restablecimiento.
Tres flujos coordinados, todos operan en el mismo gateway que el inicio de sesión y el MFA.
Un usuario con sesión iniciada cambia su contraseña introduciendo su contraseña actual y la nueva. Los action tokens, la protección CSRF y las ventanas cortas de un solo uso defienden el formulario de cambio contra el replay de sesión y el abuso cross-site; la operación vive en el mismo flujo de auditoría que cualquier otra decisión de acceso.
Un usuario que no puede iniciar sesión introduce su identificador de usuario en el formulario de olvido. La UI no confirma si la cuenta existe — siempre muestra la misma respuesta neutral — y el correo de restablecimiento se entrega mediante el proveedor de identidad configurado; así, la dirección nunca se revela de vuelta al solicitante.
El enlace de restablecimiento transporta un token de un solo uso y limitado en el tiempo almacenado en Redis. Una vez consumido, el token se invalida; cuando la ventana expira, el enlace muere. Reproducir una URL de restablecimiento filtrada falla, y la ruta de reinicio para el solicitante original es clara.
Los intentos de cambio, las solicitudes de olvido, los consumos de enlace de restablecimiento y los rechazos de política escriben entradas de auditoría estructuradas. El flujo de auditoría se alimenta al destino SIEM de la plataforma; así, los patrones de la línea de soporte, las concentraciones de anomalías y los eventos individuales aparecen desde la misma línea de tiempo que la telemetría de inicio de sesión.
Tres flujos en detalle — más la ampliación de política en la hoja de ruta.
El usuario con sesión iniciada abre el formulario de cambio, proporciona la nueva contraseña junto con la actual; y el gateway valida el valor actual mediante el proveedor de identidad configurado antes de aplicar el nuevo valor. Los tokens CSRF, los action tokens de un solo uso con TTL corto y el registro de auditoría protegen toda la operación.
Un usuario anónimo introduce su identificador de usuario en el formulario de olvido. La respuesta es la misma independientemente de si la cuenta existe o no — sin fuga de enumeración de cuentas, sin rutas de error distintas. Si el identificador de usuario coincide con una cuenta real, el proveedor de identidad configurado genera un token de restablecimiento y lo envía a la dirección registrada del usuario.
Los enlaces de restablecimiento transportan un token almacenado en Redis que el gateway valida a la llegada del enlace. Los tokens son de un solo uso y limitados en el tiempo — una vez consumidos, el token se invalida, y cuando la ventana configurada expira, el enlace deja de funcionar. Reproducir un enlace filtrado o usar un correo reenviado después de que la ventana expira falla de forma limpia.
Las direcciones de correo electrónico, los números de teléfono y los valores de identificador de usuario que se muestran de vuelta al usuario en los flujos de olvido y restablecimiento siempre se enmascaran. Un atacante que conoce la contraseña pero no tiene la bandeja de entrada no puede leer la dirección de destino; alguien que mira por encima del hombro de otra persona no puede recopilar los detalles de contacto.
AAM no almacena las contraseñas directamente. Las acciones de cambio, olvido y restablecimiento se delegan al proveedor de identidad que es el dueño de la credencial — LDAP/AD, base de datos local, OIDC pass-through u otro proveedor configurado. El flujo permanece igual; el almacenamiento permanece en el proveedor en el que ya confía.
Cada formulario de contraseña — cambio, olvido, restablecimiento — requiere un token CSRF válido ligado a la sesión o al contexto de acción del usuario. Las solicitudes cross-site que intentan abusar de la página de contraseña del usuario con sesión iniciada fallan en el gateway antes de llegar al proveedor de identidad.
Las reglas de complejidad — longitud, clases de caracteres, rechazo de contraseñas débiles/filtradas, horizonte de historial — son aplicadas hoy por cada proveedor de identidad. Una política centralizada a nivel de AAM con un único conjunto de reglas configurable que se superponga a todos los proveedores está en la hoja de ruta; así, los equipos de cumplimiento pueden expresar una única política y lograr que se evalúe en cada backend.
La política de rotación por caducidad de contraseñas y la integración con listas de credenciales filtradas (para que los usuarios no puedan establecer una contraseña conocida en una filtración pública) están en la hoja de ruta. El mismo flujo de auditoría registrará los eventos de rotación forzada y los rechazos de lista de filtraciones junto con las operaciones ordinarias del ciclo de vida.
La mecánica que mantiene seguros los flujos de contraseña de autoservicio en la capa de acceso.
Las operaciones de contraseña usan, de forma deliberada, action tokens de un solo uso con ventanas de tiempo cortas. El action token del formulario de cambio vive 30 segundos mientras el formulario está abierto; el token del enlace de restablecimiento vive solo durante la ventana configurada. El replay, el reenvío de enlaces y el abuso de token de sesión chocan primero contra estas ventanas cortas.
La generación y el consumo de tokens viven en Redis; así, cualquier pod de gateway puede validar cualquier token. Los despliegues escalados horizontalmente permanecen consistentes sin sobrecarga de coordinación; un token consumido en un pod se invalida al instante en todos los demás pods.
Cada servicio puede mapear las operaciones de contraseña a un proveedor de identidad distinto — LDAP/AD para los empleados, base de datos local para los contratistas, OIDC pass-through para las identidades federadas. La superficie del flujo permanece igual; los usuarios siempre ven una experiencia de contraseña consistente.
Los valores de contraseña se transportan solo por TLS y nunca se escriben en logs, nunca se reflejan en mensajes de error, nunca se muestran en la consola del administrador. Los metadatos del operador (hora del último cambio, estado de bloqueo, intentos de restablecimiento) son visibles; la propia contraseña no.
Los intentos de cambio fallidos, los enlaces de restablecimiento caducados y los envíos abusivos del formulario de olvido alimentan los mismos contadores de intentos que usa la capa de login-attack-protection de la plataforma. Un atacante no puede hacer fuerza bruta sobre el formulario de cambio mientras espera un intento paralelo en la página de inicio de sesión.
Para los usuarios que han perdido sus authenticators y su correo de recuperación, está en la hoja de ruta un flujo formal de recuperación mediado por administrador. El flujo reejecutará la autenticación, generará un nuevo registro y creará un único registro auditado para la acción de recuperación.
Los usuarios rotan sus contraseñas desde la página de perfil sin abrir un ticket de la línea de soporte. El mismo gateway que les permite iniciar sesión también les permite cambiar sus credenciales, y la operación cae en el mismo flujo de auditoría que el resto de las actividades de sesión.
Un usuario que no puede iniciar sesión solicita un restablecimiento, lo completa con un enlace de correo electrónico de un solo uso dentro de la ventana configurada y vuelve al trabajo. Sin participación de la línea de soporte, sin contraseña temporal compartida, sin correo de recuperación en texto plano atascado como una puerta lateral.
Los contratistas se incorporan con un flujo de cambio obligatorio en el primer inicio de sesión y se desvinculan con un restablecimiento disparado por el administrador; el restablecimiento invalida al instante todas las sesiones activas. Los momentos del ciclo de vida producen entradas de auditoría visibles para el equipo de seguridad.
Las auditorías de PCI-DSS, HIPAA, GDPR e ISO 27001 buscan pruebas de que las operaciones de contraseña se registran, se mantienen dentro del alcance y no se exponen en texto plano. El flujo de auditoría por intento y la UI de destinatario enmascarado producen esta prueba como subproducto de la operación normal.
Cambio, olvido y restablecimiento — tres flujos seguros, una única auditoría, sin puerta lateral en texto plano. Le guiaremos por una instalación en vivo sobre sus propias aplicaciones.