Solicitud MFA del VPN rechazada: qué debe hacer el cliente

Una solicitud MFA rechazada parece un problema de red y no lo es. El servidor pidió un segundo factor, el factor volvió negativo o nunca llegó, y la sesión se rechazó antes de que existiera ningún túnel. Lo que ocurre después es una cuestión de comportamiento del cliente: mostrar el fallo y dejar que el usuario inicie un intento limpio, o reintentar de maneras que generan más solicitudes y acaban activando la protección de la cuenta. El segundo camino es cómo un código mal escrito se convierte en una cuenta bloqueada.

Compruebe qué solicitud falló

Empiece identificando qué solicitud falló. Una notificación push, un código TOTP, una aserción FIDO y un flujo SAML fallan cada uno de forma distinta, y el cliente normalmente sabe cuál pidió. Una denegación, un desafío caducado y un fallo de entrega que nunca llegó al dispositivo terminan todos en el mismo error genérico, así que el estado del propio cliente suele ser el único lugar donde la diferencia sobrevive.

Ese estado merece registrarse con precisión. Registre el identificador del desafío o la referencia de la transacción, el tipo de factor, la marca temporal y el resultado, pero nunca el código ni la aserción. El identificador del desafío es lo que permite a un administrador encontrar el evento en el lado del proveedor de identidad; sin él, la conversación con el soporte empieza con «en algún momento de la última hora» y suele terminar ahí. Trátelo como metadatos de diagnóstico, no como un secreto.

Reintente una vez, a propósito, con un desafío nuevo

Un reintento debería ser un intento nuevo con un desafío nuevo, no una repetición del anterior. Cuando el cliente reutiliza el desafío anterior, el proveedor de identidad o lo rechaza por caducado o, peor, acepta una aprobación pensada para el intento anterior. Solicite un desafío nuevo, muéstrelo y deje que el usuario actúe sobre el que está ahora en pantalla.

Dos intentos con una pausa breve entre ellos es un valor por defecto razonable; un bucle sin límite no lo es. Si el segundo intento falla de la misma manera, deténgase e informe en lugar de continuar.

Lo que el cliente no debe hacer

El cliente no debe hacer varias cosas que parecen útiles y no lo son. No debe seguir enviando notificaciones push hasta que alguien toque «aprobar», porque eso entrena a los usuarios a aprobar solicitudes que no iniciaron y es exactamente el comportamiento en el que se apoyan los kits de phishing. No debe recurrir a un factor más débil porque el fuerte ha fallado, y no debe desactivar la comprobación de identidad del servidor para sortear una queja de certificado que apareció al mismo tiempo. Cada uno de esos tres atajos convierte un fallo de autenticación en un incidente de seguridad.

Tampoco debe tragarse el fallo en silencio. Un cliente que cierra la conexión y muestra un indicador de carga deja al usuario sin idea de si reintentar, esperar o llamar al soporte. Muestre el fallo con el tipo de factor y un código corto, mantenga el mensaje libre de secretos y haga la acción de reintento explícita en lugar de automática.

Si la solicitud no la inició la persona frente al teclado, la acción correcta es dejarla rechazada e informarla por la vía de soporte verificada. Aprobar una solicitud para detener el ruido es el modo de fallo, no la solución.

Qué registrar para el soporte

Para el soporte, el registro útil es pequeño. La hora aproximada con la zona horaria, la cuenta, el cliente y la versión, el tipo de factor y el estado no secreto de cada intento: solicitado, denegado, expirado, aprobado pero rechazado por la política.

Tenga también a la vista los relojes del cliente y del servidor. TOTP es una comprobación de ventana temporal, así que un dispositivo cuyo reloj se ha desviado produce códigos que parecen válidos y fallan siempre, y un cliente que informa de un código no válido sin señalar la desviación envía a la gente a restablecer credenciales que nunca estuvieron mal. Un usuario cuyo inicio de sesión falla repetidamente debería comprobar la versión compatible del cliente, el estado de inscripción y el flujo de recuperación documentado antes de generar más solicitudes.

La vía de recuperación merece el mismo cuidado que la de inicio de sesión. Un flujo para dispositivos perdidos existe precisamente para que un rechazo no se convierta en permiso para saltarse la autenticación, y un cliente debería enlazar el proceso documentado de la organización en lugar de improvisar uno.

La regla contra la que hay que construir es que el rechazo es un resultado, no un obstáculo. Infórmelo una vez, con claridad, con suficiente contexto para actuar, y deje que el siguiente intento sea nuevo. Las indicaciones de CISA sobre MFA resistente al phishing explican por qué el patrón de preguntar hasta la aprobación es peligroso de entrada, y es la referencia que vale la pena citar cuando alguien propone un bucle de reintentos. Todo lo que el cliente añada tras un rechazo debería hacer más fácil la siguiente decisión para una persona, no quitársela.