MFA resistente ao phishing: porque nem todo segundo fator é igual

A autenticação multifator não é uma coisa só. A distância entre um código de uso único enviado por SMS e uma passkey ancorada em hardware é a diferença entre abrandar um atacante e pará-lo por completo. É a distinção entre MFA phishável e MFA resistente ao phishing.

Porque a maioria da MFA continua phishável

O problema dos códigos e dos pedidos push é que o segundo fator é um segredo partilhado que a pessoa pode entregar. Se um utilizador consegue ler um código e escrevê-lo numa página, pode ser enganado a escrevê-lo na página de um atacante.

• Códigos SMS / TOTP — um proxy de atacante ao meio (AiTM) como o Evilginx apresenta um clone de início de sessão perfeito, retransmite as credenciais e o OTP em tempo real e captura o cookie de sessão resultante. O código válido não serve de nada.
• Notificações push — vulneráveis à fadiga de MFA / bombardeamento de pedidos: aprovações repetidas até um utilizador cansado tocar em «Aprovar».
• Troca de SIM (SIM swapping) — passa o número da vítima para o SIM de um atacante, derrotando o SMS por completo.

A correspondência de números e o geo-contexto no push ajudam, mas são mitigações sobre um desenho fundamentalmente phishável.

O que torna a MFA resistente ao phishing

A MFA resistente ao phishing tira a pessoa da decisão de confiança. Duas propriedades importam:

• Ligação à origem — a credencial está criptograficamente atada à origem web exata para a qual foi registada. Um domínio parecido ou proxy simplesmente não corresponde, por isso a autenticação falha em silêncio.
• Sem segredo partilhado em trânsito — a autenticação usa um desafio-resposta com uma chave privada que nunca sai do dispositivo.

As normas que o entregam:

• FIDO2 / WebAuthn — a norma de navegador e plataforma para autenticação de chave pública.
• Passkeys — credenciais FIDO2, ou ligadas ao dispositivo (chave de segurança de hardware, p. ex. YubiKey) ou sincronizadas (guardadas num ecossistema de fornecedor como Apple, Google ou um gestor de palavras-passe).
• PIV / cartões inteligentes (x.509) — a abordagem consagrada de empresas e administração pública.

Porque os proxies AiTM falham contra ela

Utilizador → phish.example (proxy do atacante) → real.example

A asserção WebAuthn é assinada sobre a origem que o navegador vê:
  clientDataJSON.origin = "https://phish.example"
A credencial foi registada para "https://real.example"
→ discrepância de origem → o autenticador/RP rejeita a asserção

Não há código que o utilizador retransmita nem cookie que o proxy colha, porque o início de sessão nunca tem êxito contra a origem errada. É o navegador que o impõe — não a pessoa.

Implementá-la sem partir nada

Priorize por risco. Comece por administradores, finanças, quadros superiores e qualquer pessoa com acesso aos sistemas mais críticos. São as contas que os kits AiTM visam primeiro.

Planeie a recuperação de conta. A recuperação é o novo ponto fraco — se uma chave perdida recua para SMS ou uma chamada ao help desk, reintroduziu o caminho phishável. Exija dois autenticadores registados por utilizador (p. ex. uma chave de segurança mais uma passkey de plataforma) e reforce a verificação de identidade no help desk.

Faça a gestão de parques mistos. As passkeys sincronizadas facilitam a implementação em dispositivos pessoais e móveis; as chaves ligadas ao dispositivo servem cenários de alta garantia e partilhados/quiosque. Muitas organizações usam ambos.

Sequencie a migração:

1. Ative FIDO2/passkeys a par da MFA existente.
2. Registe um segundo fator e conduza campanhas de inscrição.
3. Passe as funções privilegiadas para resistente ao phishing obrigatório.
4. Remova o SMS e a voz como fatores.
5. Alargue o requisito de resistência ao phishing a toda a organização via acesso condicional.

Aponte para que o resistente ao phishing seja obrigatório, e não apenas disponível. Enquanto existir um recuo phishável, os atacantes encaminham os utilizadores para lá — uma técnica conhecida como downgrade de MFA.

Como ajuda a GottaPhish

A MFA phishável — OTP e push — dá uma falsa sensação de segurança enquanto deixa uma lacuna real que os atacantes exploram ativamente; ter a tecnologia não a fecha. A GottaPhish e a sua equipa de especialistas ajudam-no a construir o argumento de negócio e a executar a implementação: as nossas simulações ao estilo AiTM demonstram, de forma segura e mensurável, como a MFA por OTP e push cai perante um proxy real, dando à liderança a evidência para financiar a MFA resistente ao phishing. A partir daí, os nossos especialistas orientam a sua adoção de FIDO2/passkeys de forma prática — priorizando funções de alto risco, planeando a inscrição com duplo autenticador e a recuperação, e reportando a adoção a par das suas métricas de clique e de comunicação — e ajudam a interpretar os resultados, para que possa provar que a lacuna phishável está mesmo a fechar.