Solicitude MFA do VPN rexeitada: que debe facer o cliente

Unha solicitude MFA rexeitada parece un problema de rede e non o é. O servidor pediu un segundo factor, o factor volveu negativo ou nunca chegou, e a sesión rexeitouse antes de que existise ningún túnel. O que ocorre despois é unha cuestión de comportamento do cliente: mostrar o fallo e deixar que o usuario comece un intento limpo, ou reintentar de maneiras que xeran máis solicitudes e acaban activando a protección da conta. O segundo camiño é como un código mal escrito se converte nunha conta bloqueada.

Comprobe que solicitude fallou

Comece identificando que solicitude fallou. Unha notificación push, un código TOTP, unha aserción FIDO e un fluxo SAML fallan cada un de forma distinta, e o cliente normalmente sabe cal pediu. Unha denegación, un desafío caducado e un fallo de entrega que nunca chegou ao dispositivo rematan todos no mesmo erro xenérico, así que o estado do propio cliente adoita ser o único lugar onde a diferenza sobrevive.

Ese estado merece rexistrarse con precisión. Rexistre o identificador do desafío ou a referencia da transacción, o tipo de factor, a marca temporal e o resultado, pero nunca o código nin a aserción. O identificador do desafío é o que permite a un administrador atopar o evento no lado do provedor de identidade; sen el, a conversa co soporte comeza con «nalgún momento da última hora» e adoita rematar aí. Tráteo como metadatos de diagnóstico, non como un segredo.

Reintente unha vez, deliberadamente, cun desafío novo

Un reintento debería ser un intento novo cun desafío novo, non unha repetición do anterior. Cando o cliente reutiliza o desafío anterior, o provedor de identidade ou o rexeita por caducado ou, peor, acepta unha aprobación pensada para o intento anterior. Solicite un desafío novo, móstreo e deixe que o usuario actúe sobre o que está agora na pantalla.

Dous intentos cunha pausa curta entre eles é un valor por defecto razoable; un bucle sen límite non o é. Se o segundo intento falla do mesmo xeito, detéñase e informe en lugar de continuar.

O que o cliente non debe facer

O cliente non debe facer varias cousas que parecen útiles e non o son. Non debe seguir enviando notificacións push ata que alguén toque «aprobar», porque iso adestra os usuarios a aprobar solicitudes que non iniciaron e é exactamente o comportamento no que se apoian os kits de phishing. Non debe recorrer a un factor máis feble porque o forte fallou, e non debe desactivar a comprobación de identidade do servidor para sortear unha queixa de certificado que apareceu ao mesmo tempo. Cada unha desas tres atallos converte un fallo de autenticación nun incidente de seguridade.

Tampouco debe tragar o fallo en silencio. Un cliente que pecha a conexión e mostra un indicador de carga deixa o usuario sen idea de se reintentar, esperar ou chamar o soporte. Mostre o fallo co tipo de factor e un código curto, manteña a mensaxe libre de segredos e faga a acción de reintento explícita en lugar de automática.

Se a solicitude non a iniciou a persoa diante do teclado, a acción correcta é deixala rexeitada e informala pola vía de soporte verificada. Aprobar unha solicitude para deter o ruído é o modo de fallo, non a solución.

Que rexistrar para o soporte

Para o soporte, o rexistro útil é pequeno. A hora aproximada coa zona horaria, a conta, o cliente e a versión, o tipo de factor e o estado non secreto de cada intento: solicitado, denegado, expirado, aprobado pero rexeitado pola política.

Teña tamén á vista os reloxos do cliente e do servidor. TOTP é unha comprobación de xanela temporal, así que un dispositivo cuxo reloxo se desviou produce códigos que parecen válidos e fallan sempre, e un cliente que informa dun código non válido sen sinalar a desviación envía a xente a restablecer credenciais que nunca estiveran mal. Un usuario cuxo inicio de sesión falla repetidamente debería comprobar a versión compatible do cliente, o estado de inscrición e o fluxo de recuperación documentado antes de xerar máis solicitudes.

A vía de recuperación merece o mesmo coidado que a de inicio de sesión. Un fluxo para dispositivos perdidos existe precisamente para que un rexeitamento non se converta en permiso para saltar a autenticación, e un cliente debería ligar o proceso documentado da organización en lugar de improvisar un.

A regra contra a que hai que construír é que o rexeitamento é un resultado, non un obstáculo. Infórmelo unha vez, con claridade, con suficiente contexto para actuar, e deixe que o seguinte intento sexa novo. As indicacións de CISA sobre MFA resistente ao phishing explican por que o patrón de preguntar ata a aprobación é perigoso de entrada, e é a referencia que paga a pena citar cando alguén propón un bucle de reintentos. Todo o que o cliente engada tras un rexeitamento debería facer máis doada a seguinte decisión para unha persoa, non quitarlle a decisión.