Aplicativo autenticador e SMS caem no mesmo ataque

Existe uma hierarquia informal que quase todo mundo aceita: SMS é ruim, aplicativo autenticador é seguro. Trocar um pelo outro virou conselho padrão.

A troca melhora alguma coisa. Só que não a que importa — e o documento que classifica autenticadores é explícito sobre isso.

O critério que separa os fatores

O NIST, no padrão que define níveis de garantia de identidade, define resistência a phishing como a capacidade do protocolo de impedir que o segredo chegue a um verificador impostor:

"phishing resistance is the ability of the authentication protocol to prevent the disclosure of authentication secrets and valid authenticator outputs to an impostor verifier (i.e., an attacker fraudulently posing as the verifier) without relying on the vigilance of the claimant"

— NIST SP 800-63B, seção 3.2.5

A última parte é a que organiza tudo. A pergunta não é quanto um fator protege. É se a proteção depende de você perceber que está no site errado.

Sob esse critério, o padrão lista como não resistentes a phishing: senhas, códigos de uso único, autenticação fora de banda — e, explicitamente, OTP. Isso cobre o SMS e cobre o aplicativo autenticador.

Os dois compartilham a mesma fraqueza estrutural: geram um código que você lê num lugar e digita em outro. Qualquer coisa capaz de se passar pelo site verdadeiro recebe esse código das suas mãos.

Onde SMS é de fato pior

A equivalência tem limite, e vale ser preciso.

O padrão trata o SMS como autenticador restrito — a única categoria assim classificada. Restrito significa que ainda pode ser usado, mas com condições: quem oferece precisa disponibilizar alternativa, e deve considerar sinais de risco como troca de chip e portabilidade antes de enviar o código.

Ou seja: SMS é pior, e é pior por um motivo específico — a linha telefônica pode ser tomada. O aplicativo autenticador não tem esse problema.

O que ele também não tem é resistência a phishing.

O ataque que não se importa com qual dos dois você usa

Em março de 2026, a Microsoft publicou uma análise de um kit de phishing que operava como serviço. Os números dão a dimensão:

"tens of millions of phishing messages reaching over 500,000 organizations each month worldwide"

A mecânica descrita é o que interessa aqui. O ataque não tenta adivinhar nem interceptar o código. Ele fica no meio: a vítima acessa uma página falsa, digita a senha, recebe o desafio, e o próprio código é repassado ao serviço verdadeiro em tempo real.

"The MFA codes were subsequently relayed through Tycoon2FA's proxy servers to the authenticating service"

Do ponto de vista da vítima, deu tudo certo. A autenticação funcionou. Ela funcionou para o atacante.

E há um detalhe que muda a resposta ao incidente: o que é roubado não é só a credencial, é o cookie de sessão gerado pela autenticação bem-sucedida. Sessão válida não pede senha de novo. Por isso "troquei a senha depois" costuma não encerrar o acesso — a porta que ficou aberta não é a senha.

Por que proteger a linha telefônica não resolve

Boa parte do esforço contra fraude de autenticação, no Brasil e fora, se concentrou em dificultar a tomada da linha: mais verificação para trocar chip, prazos após alteração cadastral, checagem de identidade na portabilidade.

São medidas legítimas e reduzem uma classe inteira de golpe.

Só que o ataque descrito acima não toca no seu chip. Não precisa da sua linha, não precisa do seu aparelho, não precisa que você perca o sinal. Precisa que você digite o código na página errada.

Endurecer a troca de chip protege contra tomada de linha. Não protege contra phishing — e concluir "agora o SMS está seguro" é trocar um risco por uma sensação.

O que muda de patamar

Segundo o mesmo padrão, resistência a phishing aparece nos autenticadores criptográficos, e por dois caminhos: amarrar a resposta ao canal de comunicação, ou amarrá-la ao identificador do verificador. É o segundo que interessa à maioria das organizações, e é o mecanismo por trás de WebAuthn — a base das passkeys e das chaves de segurança físicas.

A diferença prática é simples de enunciar. Nesses métodos o segredo nunca sai do dispositivo, e a resposta só é gerada para o domínio verdadeiro. Numa página impostora, não há o que digitar errado: o autenticador simplesmente não responde.

A vigilância do usuário deixa de ser parte da defesa. Que era exatamente o critério.

O que fazer com isso

Para quem decide autenticação numa organização, a leitura é de prioridade, não de perfeição:

Onde há dado sensível ou dinheiro, o alvo é phishing-resistant. Passkey ou chave física. É a única categoria que muda a natureza do problema, e não só a dificuldade.

Onde ainda não dá, aplicativo é melhor que SMS — pela tomada de linha, não por phishing. Continua sendo um código que pode ser entregue a quem não devia.

Trate sessão como credencial. Se o incidente foi phishing, trocar senha não basta: sessões precisam ser encerradas, e é aí que a resposta costuma falhar.

A pergunta útil não é "eu uso dois fatores?". É: se eu cair numa página convincente, meu segundo fator me salva sozinho, ou depende de eu notar?

---

Fontes

NIST SP 800-63B — Digital Identity Guidelines, seção Authenticators, National Institute of Standards and Technology.

Inside Tycoon2FA: how a leading AiTM phishing kit operated at scale, Microsoft Security Blog, 4 de março de 2026.