Todo fluxo de autenticação por SMS parece simples até o dia em que ele falha em produção. Um código que demora oito segundos para chegar, uma operadora que bloqueia mensagens de um provedor específico, um usuário legítimo travado no cadastro porque o número dele foi sinalizado como suspeito — nenhum desses problemas aparece no protótipo. Todos aparecem depois, quando o volume de usuários reais expõe as partes do sistema que ninguém testou de verdade.
Esse artigo é sobre essas partes.
O SMS como segundo fator, não como identidade
Vale separar dois conceitos que costumam se misturar em discussões de autenticação: verificação de posse e verificação de identidade. Um código OTP enviado por SMS comprova que quem está do outro lado tem acesso físico àquele número naquele momento — nada mais. Não comprova quem é a pessoa, não comprova que o número pertence a ela de forma permanente, e não substitui outras camadas de verificação quando o risco da operação exige mais.
É por isso que SMS costuma aparecer como segundo fator (2FA), somado a senha ou biometria, e raramente como fator único em produtos que lidam com dinheiro ou dados sensíveis. Tratá-lo como prova de identidade completa é o erro de arquitetura mais comum que vejo em projetos que decidem simplificar o onboarding cedo demais.
Números, reputação e deliverability
Um código gerado corretamente pelo backend não garante que ele chegue. A entrega de SMS passa por uma cadeia de intermediários — provedor, agregador, operadora de destino — e cada elo dessa cadeia avalia a reputação do número de origem antes de entregar a mensagem. Números novos, números reciclados sem histórico, ou números associados a picos anormais de envio tendem a sofrer atraso ou bloqueio silencioso, sem erro explícito na API.
Isso tem uma implicação direta para quem opera número próprio para testes, QA ou contas de serviço: um número virtual usado de forma consistente ao longo do tempo constrói reputação, exatamente como acontece com IP de e-mail transacional. Um número usado de forma esporádica, ou trocado com frequência, reinicia esse histórico e volta a sofrer com atrasos que parecem bugs, mas são comportamento normal de operadora.
Rate limiting e o custo escondido do abuso
Todo endpoint de envio de OTP é, por definição, um alvo de abuso: gera custo real por mensagem e pode ser usado para floodar um número de terceiro. Rate limiting por IP, por conta e por número de destino é obrigatório, não opcional — e vale aplicar em camadas diferentes, porque um atacante que rotaciona IP ainda esbarra no limite por número, e vice-versa.
Times que pulam essa etapa geralmente descobrem o problema pela fatura do provedor de SMS, não por um alerta de segurança. É um dos poucos casos em que o incidente aparece primeiro no financeiro.
SIM swapping e os limites do SMS como segundo fator
SIM swapping — quando um atacante transfere o número da vítima para um chip sob seu controle, geralmente por engenharia social junto à operadora — é o principal motivo pelo qual especialistas em segurança recomendam SMS apenas como uma camada entre várias, nunca como único fator para operações de alto risco. Apps de autenticação (TOTP) e chaves físicas não dependem da rede de telefonia e não são vulneráveis ao mesmo vetor.
Isso não invalida o SMS como ferramenta — continua sendo a opção mais acessível para a maioria dos usuários, sem exigir instalar outro app. Mas informa onde ele deve ficar na arquitetura: fator complementar, com fallback e camadas adicionais para operações sensíveis.
Onde o número virtual entra nesse desenho
Separado do gateway que envia OTP em escala para usuários finais, existe a necessidade operacional de ter um ou mais números controlados pelo próprio time — para testar fluxos de terceiros, manter contas de serviço que também exigem verificação, ou dar a membros da equipe uma linha de trabalho sem expor o número pessoal. Um serviço como o numero virtual resolve exatamente essa camada: um número estável, sem depender de chip físico, com histórico de uso que se acumula ao longo do tempo em vez de reiniciar a cada troca.
Não é ferramenta de envio em massa. É infraestrutura de posse de número — a peça que costuma faltar entre "temos uma API de SMS" e "temos controle real sobre os números que usamos para operar e testar o próprio sistema".
LGPD e o número como dado pessoal
Vale lembrar que número de telefone é dado pessoal sob a LGPD, com as mesmas obrigações de qualquer outro dado identificável: base legal para coleta, finalidade explícita, e retenção limitada ao necessário. Números usados internamente para testes ou contas de serviço não estão isentos dessa análise só por não pertencerem a um cliente final — vale mapear onde esses números são armazenados e por quanto tempo, como parte do mesmo inventário de dados pessoais da aplicação.
Resumo
Autenticação por SMS funciona bem quando tratada como o que é: uma camada de verificação de posse, sujeita a limites de entrega, custo de abuso e um vetor de ataque conhecido, que precisa de rate limiting, fallback e — na maioria dos casos — reforço com outros fatores para operações sensíveis. A parte menos discutida, mas igualmente relevante, é a gestão dos próprios números usados pelo time para operar, testar e manter esse sistema — que é onde a reputação, a estabilidade e o controle sobre um número virtual dedicado fazem diferença prática no dia a dia de quem mantém esse tipo de fluxo em produção.
Top comments (0)