Pedido MFA da VPN rejeitado: o que o cliente deve fazer

Um pedido MFA rejeitado parece um problema de rede e não é. O servidor pediu um segundo fator, o fator voltou negativo ou nunca chegou, e a sessão foi recusada antes de existir qualquer túnel. O que acontece a seguir é uma questão de comportamento do cliente: mostrar a falha e deixar o utilizador iniciar uma tentativa limpa, ou repetir de formas que geram mais pedidos e acabam por ativar a proteção da conta. O segundo caminho é como um código mal escrito se transforma numa conta bloqueada.

Verifique qual pedido falhou

Comece por identificar qual pedido falhou. Uma notificação push, um código TOTP, uma asserção FIDO e um fluxo SAML falham cada um de forma diferente, e o cliente normalmente sabe qual pediu. Uma recusa, um desafio expirado e uma falha de entrega que nunca chegou ao dispositivo terminam todos no mesmo erro genérico, pelo que o estado do próprio cliente é muitas vezes o único lugar onde a diferença sobrevive.

Vale a pena registar esse estado com precisão. Registe o identificador do desafio ou a referência da transação, o tipo de fator, a marca temporal e o resultado, mas nunca o código ou a asserção. O identificador do desafio é o que permite a um administrador encontrar o evento do lado do fornecedor de identidade; sem ele, a conversa com o suporte começa com «algures na última hora» e normalmente termina aí. Trate-o como metadados de diagnóstico, não como um segredo.

Tente novamente uma vez, deliberadamente, com um novo desafio

Uma nova tentativa deve ser uma tentativa nova com um desafio novo, não uma repetição do antigo. Quando o cliente reutiliza o desafio anterior, o fornecedor de identidade ou o rejeita por estar desatualizado ou, pior, aceita uma aprovação destinada à tentativa anterior. Peça um desafio novo, mostre-o e deixe o utilizador agir sobre o que está agora no ecrã.

Duas tentativas com uma pausa curta entre elas é um valor predefinido razoável; um ciclo ilimitado não é. Se a segunda tentativa falhar da mesma forma, pare e comunique em vez de continuar.

O que o cliente não deve fazer

O cliente não deve fazer várias coisas que parecem úteis e não são. Não deve continuar a enviar notificações push até alguém tocar em «aprovar», porque isso treina os utilizadores a aprovar pedidos que não iniciaram e é exatamente o comportamento com que contam os kits de phishing. Não deve recuar para um fator mais fraco por o forte ter falhado, e não deve desativar a verificação de identidade do servidor para contornar uma queixa de certificado que apareceu ao mesmo tempo. Cada um desses três atalhos transforma uma falha de autenticação num incidente de segurança.

Também não deve engolir a falha em silêncio. Um cliente que fecha a ligação e mostra um indicador de carga deixa o utilizador sem ideia de se deve tentar de novo, esperar ou telefonar ao suporte. Mostre a falha com o tipo de fator e um código curto, mantenha a mensagem livre de segredos e torne a ação de nova tentativa explícita em vez de automática.

Se o pedido não foi iniciado pela pessoa ao teclado, a ação correta é deixá-lo rejeitado e comunicá-lo pelo caminho de suporte verificado. Aprovar um pedido para parar o ruído é o modo de falha, não a correção.

O que registar para o suporte

Para o suporte, o registo útil é pequeno. A hora aproximada com o fuso horário, a conta, o cliente e a versão, o tipo de fator e o estado não secreto de cada tentativa: pedido, negado, expirado, aprovado mas rejeitado pela política.

Tenha também em atenção os relógios do cliente e do servidor. O TOTP é uma verificação de janela temporal, pelo que um dispositivo cujo relógio desviou produz códigos de aspeto válido que falham sempre, e um cliente que comunica um código inválido sem notar o desvio envia as pessoas a repor credenciais que nunca estiveram erradas. Um utilizador cujo login falha repetidamente deve verificar a versão suportada do cliente, o estado de inscrição e o fluxo de recuperação documentado antes de gerar mais pedidos.

O caminho de recuperação merece o mesmo cuidado que o caminho de login. Um fluxo para dispositivo perdido existe precisamente para que uma recusa não se torne permissão para contornar a autenticação, e um cliente deve ligar ao processo documentado da organização em vez de improvisar um.

A regra sobre a qual construir é que a recusa é um resultado, não um obstáculo. Comunique-a uma vez, com clareza, com contexto suficiente para agir, e deixe a tentativa seguinte ser nova. As orientações da CISA sobre MFA resistente a phishing explicam porque é que o padrão de «perguntar até ser aprovado» é perigoso desde o início, e é a referência que vale a pena citar quando alguém propõe um ciclo de novas tentativas. Tudo o que o cliente acrescenta após uma recusa deve tornar a decisão seguinte mais fácil para uma pessoa, não retirar-lhe a decisão.