A autenticação multifator (MFA) tornou-se uma camada básica de segurança digital, mas a evolução dos ataques de phishing — especialmente os ataques adversariais em tempo real (AiTM, do inglês Adversary-in-the-Middle) — expôs fragilidades graves nos métodos tradicionais baseados em códigos OTP e notificações push. O conceito de MFA resistente a phishing surgiu precisamente para fechar essa lacuna, garantindo que o segundo fator não possa ser interceptado, replicado ou induzido pelo atacante. Este artigo analisa o que muda concretamente quando uma organização ou usuário migra de um MFA convencional para uma solução genuinamente resistente a phishing.
Por que o MFA tradicional para de funcionar
Durante anos, a recomendação padrão foi habilitar a verificação em duas etapas por meio de códigos SMS, tokens OTP via aplicativo ou aprovação de notificações push. A Cartilha de Segurança para Internet do CERT.br documenta extensivamente a importância desses mecanismos como melhoria em relação ao uso exclusivo de senhas [1][2]. No entanto, esses métodos compartilham uma limitação estrutural fundamental: o fator de autenticação é um segredo compartilhado (shared secret) que transita ou pode ser reproduzido no mesmo canal onde ocorre o ataque.
Em um ataque AiTM, o atacante opera um proxy reverso entre o usuário e o serviço legítimo. O usuário acessa uma página que se parece com o portal real, digita sua senha e, em seguida, recebe ou consulta o código OTP. O atacante repassa a senha e o código em tempo real para o serviço legítimo, concluindo a autenticação antes que o token expire. O mesmo acontece com notificações push maliciosas que geram fadiga no usuário até que ele aprove o acesso sem ler o conteúdo. Esse cenário demonstra que o MFA baseado em segredos compartilhados não distingue o contexto da sessão — ele valida apenas a posse do segredo, não quem está solicitando o acesso.
O que torna um MFA resistente a phishing
Um MFA é considerado resistente a phishing quando sua arquitetura impede que um atacante, mesmo controlando totalmente o canal de comunicação com a vítima, consiga obter ou reproduzir o fator de autenticação necessário para concluir o login. Isso é alcançado eliminando o uso de segredos compartilhados e substituindo-os por criptografia assimétrica vinculada à identidade do servidor de destino.
Na prática, isso significa que o dispositivo de autenticação do usuário verifica ativamente o domínio ao qual ele está se autenticando. Se o usuário estiver sendo enganado por um site fraudulento, o domínio apresentado não corresponderá ao domínio registrado na credencial FIDO2, e a autenticação será recusada automaticamente — independentemente de o usuário ter sido enganado visualmente. Essa verificação criptográfica do domínio é o que diferencia de forma categórica um MFA resistente a phishing de um MFA que apenas adiciona um passo extra ao fluxo de login [4][6].
FIDO2 e chaves de acesso (passkeys) como referência
O padrão FIDO2, desenvolvido pela FIDO Alliance e pelo W3C, é a implementação mais madura e difundida de MFA resistente a phishing. Ele utiliza pares de chaves criptográficas assimétricas em que a chave privada nunca deixa o dispositivo do usuário, e a chave pública é registrada no servidor. Durante a autenticação, o servidor envia um desafio criptográfico que inclui o domínio de origem. O autenticador assina esse desafio somente se o domínio corresponder ao registrado, tornando impossível para um proxy malicioso reutilizar a resposta em outro contexto.
As chaves de acesso (passkeys) representam a evolução mais recente desse padrão, eliminando a necessidade de senhas e armazenando as credenciais FIDO2 de forma sincronizada entre dispositivos do mesmo ecossistema (por exemplo, via iCloud Keychain ou Google Password Manager). Para o usuário final, a experiência se resume a uma biometria ou PIN no dispositivo, mas por trás da tela existe uma verificação criptográfica robusta que neutraliza ataques de phishing de forma estrutural, não comportamental.
Comparativo técnico entre métodos de MFA
A tabela abaixo sintetiza as diferenças fundamentais entre as categorias de MFA, evidenciando por que a resistência a phishing não é uma questão de grau, mas de arquitetura:
| Método de MFA | Tipo de segredo | Vulnerável a AiTM | Verifica domínio | Resistência a phishing |
|---|---|---|---|---|
| SMS / OTP por app | Segredo compartilhado | Sim | Não | Baixa |
| Push notification (padrão) | Segredo compartilhado | Sim | Não | Baixa |
| Push com número de contexto | Segredo compartilhado | Parcialmente | Indiretamente | Média |
| Hardware token OTP (TOTP) | Segredo compartilhado | Sim | Não | Baixa |
| Hardware token FIDO2 (ex.: YubiKey) | Chave assimétrica | Não | Sim | Alta |
| Passkey (chave de acesso) | Chave assimétrica sincronizada | Não | Sim | Alta |
Ataques adversariais em tempo real (AiTM) em detalhe
Os ataques AiTM se tornaram a principal ferramenta de grupos de ameaça avançada e criminosos cibernéticos que buscam contornar o MFA. Ferramentas como Evilginx, Modlishka e GoPhish permitem configurar proxies reversos com certificados TLS válidos, criando páginas indistinguíveis dos portais legítimos para o usuário comum. Quando a vítima insere suas credenciais nesses proxies, o atacante captura tanto a senha quanto o token de sessão (session cookie) gerado após a autenticação bem-sucedida.
O resultado é que, mesmo com MFA ativo, o atacante obtém um token de sessão válido que pode ser injetado em sua própria navegação, bypassando completamente a necessidade de autenticar novamente. Esse tipo de ataque tem sido amplamente documentado em campanhas direcionadas contra organizações financeiras, governamentais e corporativas [3]. A gravidade do problema é que nenhuma melhoria na complexidade da senha ou na política de expiração de OTP resolve a questão, porque o ponto de falha está na arquitetica do protocolo de autenticação, não no comportamento do usuário.
O que muda na prática para organizações
Para equipes de segurança da informação, a transição de MFA tradicional para MFA resistente a phishing implica mudanças em múltiplas camadas. Primeiro, é necessário avaliar quais aplicações e serviços suportam os padrões FIDO2/WebAuthn nativamente. Plataformas como Microsoft Entra ID, Google Workspace, Okta e GitHub já oferecem suporte robusto, mas muitos sistemas legados ainda dependem exclusivamente de senhas e OTP, exigindo adaptações de infraestrutura ou a adoção de gateways de autenticação compatíveis com FIDO2.
Segundo, a distribuição de credenciais precisa ser repensada. Enquanto o OTP pode ser provisionado por um simples QR code escaneado por qualquer aplicativo, as chaves FIDO2 exigem um processo de registro vinculado ao dispositivo específico. Organizações que adotam chaves de segurança físicas precisam definir políticas de emissão, substituição e revogação. Terceiro, o monitoramento de segurança muda de foco: em vez de investigar tentativas de bypass de MFA por força bruta, as equipes passam a se concentrar em tentativas de phishing que falham silenciosamente (porque o FIDO2 as bloqueia) e em vetores alternativos, como comprometimento de sessão por malware no endpoint ou tokens de atualização roubados.
O que muda para o usuário final
Do ponto de vista do usuário comum, a experiência de autenticação com MFA resistente a phishing é paradoxalmente mais simples e mais segura. Em vez de copiar e colar códigos de seis dígitos ou aguardar notificações push, o usuário toca em seu sensor biométrico ou insere um PIN no dispositivo. A complexidade criptográfica é invisível. No entanto, existe uma mudança cultural importante: o usuário precisa compreender que sua credencial está vinculada ao dispositivo, e a perda ou comprometimento desse dispositivo tem implicações diferentes de esquecer uma senha.
As chaves de acesso (passkeys) mitigam parcialmente esse problema ao permitir sincronização entre dispositivos, mas introduzem novas questões de confiança no provedor de sincronização. A Cartilha de Segurança para Internet do CERT.br enfatiza que a segurança depende de camadas complementares [1][5], e isso permanece válido: o MFA resistente a phishing é uma camada poderosa, mas não elimina a necessidade de boas práticas como verificação de URLs, atualização de sistemas e proteção do dispositivo contra malware.
Passos para migrar de MFA tradicional para phishing-resistant MFA
A migração deve ser planejada em fases para minimizar disrupções e garantir cobertura adequada. O seguinte plano ordenado pode ser adaptado conforme o contexto da organização:
- Inventário de sistemas críticos: mapear todas as aplicações que exigem autenticação, classificando-as por criticidade e suporte a FIDO2/WebAuthn.
- Definição da estratégia de credenciais: optar por chaves de segurança físicas para usuários de alto risco, passkeys para a base geral, ou uma combinação dos dois.
- Piloto com grupo de alto risco: implementar primeiro para administradores de sistemas, desenvolvedores com acesso a produção e executivos com acesso a dados sensíveis.
- Ajuste de políticas de acesso condicional: configurar regras que exijam FIDO2 para acessos privilegiados e permitam MFA tradicional como transição para demais usuários.
- Comunicação e treinamento: educar os usuários sobre o que mudou, por que a nova abordagem é mais segura e como proceder em caso de perda do dispositivo.
- Desativação gradual de métodos vulneráveis: após confirmar estabilidade e adesão, remover OTP e push como opções de MFA para sistemas críticos, mantendo-os apenas como fallback temporário se estritamente necessário.
- Monitoramento e ajuste contínuo: analisar logs de autenticação para identificar tentativas de phishing bloqueadas, taxa de falhas de autenticação e necessidade de ajustes na experiência do usuário.
Limitações e riscos residuais
Nenhum mecanismo de segurança é imune a todas as classes de ataque. O MFA resistente a phishing elimina o vetor de interceptação de credenciais via proxy, mas não protege contra todos os cenários de comprometimento. Malware que opera no próprio dispositivo do usuário, como info-stealers que extraem tokens de sessão já ativos ou chaves privadas de passkeys armazenadas sem proteção adequada, continua sendo uma ameaça real. Da mesma forma, ataques de engenharia social que convencem o usuário a registrar uma nova credencial FIDO2 em um dispositivo controlado pelo atacante podem contornar a proteção se não houver políticas de registro restritivas.
Além disso, a dependência de fabricantes específicos de chaves de segurança cria riscos de cadeia de suprimentos. Vulnerabilidades descobertas em implementações de FIDO2, embora raras, têm ocorrido e requerem processos ágeis de atualização de firmware. A segmentação de redes, o princípio do menor privilégio e a detecção de anomalias em tempo real permanecem como controles complementares indispensáveis [2].
Cenário brasileiro e recomendações do CERT.br
No contexto brasileiro, a adoção de MFA resistente a phishing ainda é incipiente na maioria das organizações, mas gaining tração entre instituições financeiras e empresas de tecnologia de maior maturidade em segurança. O CERT.br, através da Cartilha de Segurança para Internet, tem sido um canal fundamental para difundir a importância da autenticação multifator [1][4]. Os fascículos dedicados a contas e senhas e à verificação em duas etapas estabelecem a base conceitual, mas é essencial que a comunidade de segurança brasileira avance na discussão sobre a qualidade do MFA implementado, não apenas sua existência.
A LGPD e seus desdobramentos regulatórios pressionam organizações a adotarem medidas técnicas adequadas para proteger dados pessoais, e o uso de MFA vulnerável a phishing pode ser questionado como medida insuficiente em caso de incidente. Recomenda-se que as equipes brasileiras de segurança incorporem a resistência a phishing como critério obrigatório em avaliações de soluções de autenticação e em requisitos de contratos com provedores de identidade [5][6].
Perguntas frequentes sobre MFA resistente a phishing
Qual a diferença entre MFA e MFA resistente a phishing?
O MFA tradicional adiciona fatores de autenticação (algo que você sabe, tem ou é), mas esses fatores podem ser interceptados ou induzidos em ataques de phishing em tempo real (AiTM). O MFA resistente a phishing utiliza criptografia assimétrica que verifica o domínio de destino, tornando impossível para o atacante reutilizar a credencial mesmo controlando o canal de comunicação.
Chaves de acesso (passkeys) são iguais a MFA resistente a phishing?
Passkeys são uma forma de implementar MFA resistente a phishing, pois são baseadas no padrão FIDO2 e utilizam criptografia assimétrica com verificação de domínio. No entanto, a sincronização de passkeys entre dispositivos introduz dependência do provedor de cofre de credenciais, o que adiciona um vetor de confiança que não existe em chaves de segurança físicas dedicadas.
Posso eliminar senhas completamente com MFA resistente a phishing?
Tecnicamente sim, pois o padrão FIDO2 suporta autenticação sem senha (passwordless). Na prática, a maioria das organizações adota uma abordagem híbrida em que senhas coexistem como método de fallback durante a transição. A eliminação completa depende do suporte de todos os sistemas integrados e da maturidade do processo de recuperação de conta sem senha.
O MFA resistente a phishing protege contra todos os tipos de ataque?
Não. Ele protege especificamente contra interceptação de credenciais via phishing e proxies reversos (AiTM). Não protege contra malware no dispositivo que rouba sessões ativas, contra engenharia social que leva o usuário a registrar uma credencial em dispositivo do atacante, nem contra vulnerabilidades no servidor de autenticação. Por isso deve ser parte de uma estratégia de defesa em profundidade.
Usuários comuns precisam entender criptografia para usar FIDO2?
Não. A experiência do usuário é projetada para ser transparente: o usuário toca no sensor biométrico ou insere um PIN, e a verificação criptográfica acontece em segundo plano. A compreensão técnica é importante para equipes de segurança e gestores, mas o usuário final interage com uma interface simples que não exige conhecimento criptográfico.
Fontes
[1] Fascículos — Cartilha de Segurança para Internet — CERT.br
[3] Phishing Moderno em 2026: A Nova Geração de Ataques Cibernéticos Inteligentes — Rio Forense