Verificação SMS vs aplicativos autenticadores: qual é mais seguro?

Dois fatores, dois modelos de ameaça muito diferentes

Quando um serviço pede um segundo fator, está pedindo para você provar duas coisas: que você conhece a senha e que você possui algo mais. Esse "algo mais" é o que difere entre SMS e um aplicativo autenticador, e as diferenças só importam quando você examina cenários de ataque específicos.

SMS pede ao provedor de mensagens do serviço para enviar um código de uso único para um número de telefone. A posse é estabelecida ao receber o código no dispositivo que controla esse número — o que, crucialmente, é quem controla o cartão SIM ou o roteamento do número virtual, não necessariamente você.

Aplicativos autenticadores como Google Authenticator, Authy, Aegis ou 2FAS geram códigos localmente em um dispositivo usando um segredo compartilhado que foi trocado no registro. A posse é estabelecida ao ter o dispositivo que contém o segredo. O código nunca viaja pela rede até você — é calculado no seu bolso.

Essa única diferença — códigos chegando da rede versus códigos calculados localmente — é a fonte de quase cada lacuna de segurança entre os dois métodos. As ameaças contra as quais eles protegem, as ameaças contra as quais falham e os caminhos de recuperação fluem daí.

Como códigos de uso único por SMS são atacados

A superfície de ataque do SMS é incomumente ampla porque o SMS toca vários sistemas antes de chegar até você.

SIM swap é o ataque mais divulgado e continua eficaz em 2026. Um atacante manipula socialmente um representante da operadora — ou suborna um — para transferir seu número para um SIM que ele controla. Assim que o SIM é dele, todo SMS que chegaria para você, incluindo seus códigos de reset de senha, vai para as mãos dele. A cobertura de roubos de SIM swap de alto perfil não diminuiu; a técnica é lucrativa o suficiente para que anéis semi-organizados continuem com ela.

Interceptação SS7 explora fraquezas no protocolo de sinalização interoperadora que conecta as redes telefônicas mundiais desde os anos 1980. Com acesso a um gateway SS7 — vendido discretamente em trocas de mercado cinzento — um atacante pode redirecionar o roteamento de SMS sem tocar no seu SIM. Isso exige mais habilidade do que SIM swap e é mais raro fora de ataques direcionados, mas foi demonstrado contra bancos repetidamente.

Pessoas de dentro da operadora e phishing de pessoal de suporte é uma classe relacionada. As ferramentas de atendimento ao cliente da operadora são, do ponto de vista dela, software CRM comum. Um atacante motivado que faz phishing de uma sessão de agente de suporte pode emitir transferências, alterar roteamento e ler logs de SMS.

Smishing é o ataque mais simples: um atacante envia um SMS falso que parece um pedido de verificação legítimo, na esperança de você digitar um código em uma página de phishing. Este é o único ataque aqui que aplicativos autenticadores também não falham, já que códigos de autenticador também podem ser phishing se o usuário for enganado.

O fio condutor: SMS depende de múltiplos sistemas que você não controla, e qualquer um deles sendo comprometido é suficiente. Códigos de autenticador dependem apenas de um dispositivo que você fisicamente possui.

Onde aplicativos autenticadores falham

Aplicativos autenticadores não são invulneráveis. Eles têm seus próprios modos de falha.

Phishing ainda funciona. Uma página de login falsa bem-elaborada pode pedir sua senha e seu código TOTP em tempo real, e um script atrás da página envia ambos para o serviço real antes da janela de 30 segundos expirar. Este é o ataque dominante em contas protegidas por autenticador em 2026 e a razão pela qual WebAuthn / passkeys estão lentamente deslocando TOTP.

Perda de dispositivo é fatal sem backup. Se você configurou Google Authenticator em um único telefone, perdeu o telefone e nunca salvou códigos de recuperação, você está bloqueado de cada conta. A recuperação está à mercê de cada equipe de suporte do serviço, que geralmente leva dias e requer prova de identidade.

Autenticadores sincronizados na nuvem introduzem uma nova superfície de ataque. Authy famosamente teve uma brecha em 2024 que vazou números de telefone vinculados a contas. Aplicativos autenticadores que sincronizam com iCloud ou Google Drive expõem seus seeds a quem puder comprometer essa conta. A troca é real: perca o dispositivo ou perca a nuvem, escolha qual deixa você menos incomodado.

Malware no dispositivo. Um telefone comprometido pode ler códigos TOTP de um screenshot ou gravação de tela. Este é um ataque especializado e raro contra usuários comuns, mas para alvo de alto valor é documentado.

Reutilização de OTP e desvio de hora. Se o relógio de um dispositivo se desvia, os códigos não são validados. Se o mesmo segredo é registrado em dois dispositivos e um é roubado, ambos produzem códigos válidos até o segredo ser revogado.

Uma comparação lado a lado

Leia esta tabela corretamente: não é "autenticador vence todas as linhas". SMS vence em acessibilidade, recuperação de conta e configuração sem configuração. Para um login casual em fórum, SMS é fino. Para seu banco, seu email ou sua exchange de cripto, a linha que importa é "resistente a SIM swap", e ali SMS perde muito.

Quando 2FA por SMS é a escolha certa

Existem casos reais onde 2FA por SMS é a opção melhor:

• O usuário não tem smartphone. Parentes mais velhos, certos locais de trabalho, qualquer um usando um telefone básico. SMS é o único segundo fator que eles podem usar.
• Recuperação de conta é dominante. Para contas de baixo valor, o custo de ficar bloqueado (não conseguir recuperar um login de site de receita) excede o custo de um ataque (alguém rouba suas receitas salvas).
• O modelo de ameaça é oportunista, não direcionado. Atacantes aleatórios não fazem SIM swap em pessoas aleatórias; vão atrás de alvo de alto valor. Se você não é um alvo de alto valor, SMS desvia ataques oportunistas adequadamente.
• Você está usando um número virtual. Um número de telefone virtual usado para uma conta específica, nunca vinculado à sua identidade real, é significativamente mais difícil de SIM-swap porque o atacante tem que identificar qual provedor o hospeda primeiro. Isto não elimina o risco SS7, mas aumenta a barra no ataque mais comum significativamente. Muitos usuários registram contas via fluxo de ativação de SMS precisamente para que a linha de verificação seja desacoplada do seu número principal.

O padrão "número virtual para contas de baixo risco" é cada vez mais comum: use 2FA por SMS em base por conta com números descartáveis e reserve TOTP ou chaves de hardware para contas que mantêm dinheiro ou correspondência.

Quando aplicativos autenticadores são inegociáveis

Se algum dos seguintes descreve sua conta, um aplicativo autenticador (ou, melhor, uma chave de hardware) é a linha de base correta:

• A conta mantém dinheiro — banco, corretora, exchange de cripto, processador de pagamento
• A conta mantém correspondência de longo prazo — email, especialmente o email que faz backup de outras contas
• A conta é usada para trabalho — SSO corporativo, controle de código-fonte, infraestrutura em nuvem
• A conta contém dados regulados — saúde, serviços governamentais
• A conta exporia você pessoalmente se violada — mídia social principal, aplicativos de namoro ou qualquer coisa vinculada à sua identidade real

Para estas, o risco de SIM swap domina tudo mais. Combine o autenticador com WebAuthn / uma chave de hardware onde suportado. Para exchanges de cripto especificamente, o cálculo é diferente: você geralmente precisa de ambos, porque exchanges exigem SMS como fallback mesmo depois que você configurar TOTP.

Configurações híbridas que realmente funcionam

A configuração prática mais forte para a maioria dos usuários é em camadas:

1. TOTP via um autenticador com backup como o segundo fator principal. Aegis com backups locais criptografados, 2FAS com iCloud ou Authy se você aceita o modelo de confiança em nuvem.
2. Códigos de recuperação impressos em papel armazenados offline. A maioria dos serviços fornece 8 a 16 códigos na configuração de TOTP. Trate-os como dinheiro.
3. Um número SMS virtual na conta, isolado da sua linha principal, apenas para serviços que exigem como fallback. O número não precisa ser seu número "real" — apenas precisa ser alcançável. Use um número de aluguel de longo prazo para estabilidade ou um DID dedicado para contas que você faz login frequentemente.
4. Uma chave de hardware (YubiKey, Feitian) no topo para contas que a suportam. Resistente a phishing de forma que nada mais aqui é.

Esta configuração custa talvez vinte dólares por ano (número de aluguel mais chave de hardware opcional) e protege você contra cada ataque realista a menos de compromisso completo de dispositivo.

O que migrar primeiro se você está começando hoje

Se você está lendo isto e suas contas são todas SMS-only, faça isto em ordem:

1. Email primeiro. É a conta de recuperação para tudo mais. Mude para TOTP esta semana.
2. Contas financeiras segundo. Banco, corretora, processadores de pagamento. Alguns bancos ainda resistem a TOTP — pressione-os, ou escolha um banco que o oferece.
3. Qualquer coisa vinculada à sua identidade real. Mídia social principal, portais governamentais, saúde.
4. Contas de valor a longo prazo. Armazenamento em nuvem, repositórios de código, qualquer coisa que você perderia trabalho.
5. Tudo mais. SMS é fino para a cauda longa. Se você tem centenas de contas, jogar números virtuais nelas é mais rápido do que registrar cada uma em TOTP.

O ponto de tudo isto não é que SMS é inseguro e aplicativos autenticadores são seguros. É que eles falham contra ameaças diferentes, e a escolha correta depende do que você está protegendo. Para uma perspectiva externa sobre as fraquezas SS7 subjacentes, o resumo da Wikipedia sobre ataques SS7 é um ponto de partida justo.

Escolha o segundo fator que corresponda à ameaça. Coloque-os em camadas onde importa. E se você está usando SMS tudo bem, pelo menos faça em um número que não seja também sua linha principal — essa única mudança fecha o vetor de ataque mais fácil com custo zero contínuo.