ADR: Substituindo SMS OTP por Autenticação Silenciosa no Cognito
cerca de 9 min · áudio gerado ao tocar
Em sistemas financeiros, a autenticação não é apenas um portão de entrada, é uma superfície de ataque mensurável com custo operacional direto. Quando 1 em cada 5 usuários legítimos abandona o fluxo de verificação por SMS OTP e ataques de account takeover cresceram 141% desde 2021, a decisão de manter SMS OTP como mecanismo primário precisa ser justificada como uma escolha arquitetural consciente, não como um padrão herdado. Este ADR documenta a análise que conduzi ao avaliar a substituição do fluxo SMS OTP pelo modelo de autenticação silenciosa baseada em rede móvel, integrado ao Amazon Cognito via CUSTOM_AUTH, e por que, para ambientes CIAM financeiros, essa não é uma decisão óbvia, mas uma que carrega consequências reais de cada lado.
Contexto e Forças em Jogo
O sistema em análise é uma plataforma CIAM financeira com ~4 milhões de usuários ativos mensais, operando em múltiplos países da América Latina. O fluxo de autenticação atual usa Amazon Cognito com SMS OTP via SNS para verificação de segundo fator. O custo mensal com SMS gira em torno de $18.000–$22.000, dos quais estimamos que 8–12% são originados por tráfego artificialmente inflado (AIT), um número conservador baseado em análise de logs do SNS e padrões de destino.
As forças que motivaram esta revisão são concretas:
Pressão de segurança: O time de fraude identificou três incidentes de SIM swap bem-sucedidos nos últimos seis meses, todos resultando em account takeover completo. Em todos os casos, o SMS OTP foi entregue ao atacante porque o swap já havia ocorrido antes da tentativa de autenticação. Bancos de dados estáticos de lookup de número não detectaram nenhum dos três eventos.
Pressão de conversão: A taxa de conclusão do fluxo de login mobile está em 78,3%, abaixo da média do setor de 80%. Cada ponto percentual de conversão representa aproximadamente $340.000 em receita anual para este produto específico.
Pressão regulatória: A LGPD e as diretrizes do Banco Central para Open Finance exigem que mecanismos de autenticação sejam robustos contra ataques conhecidos. SS7 é um ataque conhecido e documentado. Manter SMS como único segundo fator começa a ser questionável do ponto de vista de compliance.
Pressão de custo de suporte: O helpdesk processa aproximadamente 12.000 tickets mensais relacionados a OTP não recebido ou expirado, um custo operacional que não aparece no dashboard de segurança mas é real.
O Custo Real do SMS OTP em Escala
O Que 'Baseado em Rede' Realmente Significa, e Por Que Importa para Fraude Financeira
A distinção técnica mais importante nesta decisão não é sobre UX, é sobre a camada de onde o sinal de identidade é derivado. Ferramentas tradicionais de verificação de identidade operam sobre dados agregados, cacheados ou comportamentais. Um serviço de lookup de número de telefone consulta um banco de dados estático que pode ter dias ou semanas de defasagem. Device fingerprinting analisa características do browser que podem ser falsificadas. Biometria comportamental constrói modelos a partir de sessões históricas, útil, mas um indicador defasado por definição.
O que diferencia a abordagem de rede móvel é a camada de origem do sinal: dados em tempo real diretamente dos operadores de rede móvel (MNOs). Quando você consulta se um SIM foi trocado recentemente, você está consultando a rede que executou o swap. Quando a Silent Authentication verifica um usuário, a prova de posse é a própria sessão de dados celulares, algo que não pode ser phished, interceptado ou engenheirado socialmente porque não existe como um segredo transmissível.
Para cenários de fraude financeira onde SIM swaps são usados para account takeover, 'recentemente' significa minutos ou horas, não dias. Bancos de dados estáticos atualizados semanalmente não detectam esses eventos, eles os registram após o fato. Consultas em tempo real ao operador fecham essa janela completamente.
Essa diferença de camada tem uma implicação arquitetural direta: os controles de Identity Insights (sim_swap, device_swap, subscriber_match, recycled_number, format/network_type) precisam ser executados antes de qualquer canal de verificação ser iniciado. Isso muda o ponto de decisão de risco do pós-desafio para o pré-desafio, o que, em termos de custo, significa que tentativas fraudulentas são bloqueadas antes de um único SMS ser enviado, antes de custos de verificação serem incorridos.
Opções Consideradas
Opção A: Manter SMS OTP via Cognito + SNS (status quo)
- Zero esforço de migração; já em produção
- Suporte nativo do Cognito sem Lambda triggers customizados
- Cobertura universal, não depende de conectividade de dados celulares
- Vulnerável a SIM swap, SS7 interception e social engineering
- Taxa de abandono de ~20% em fluxos mobile
- Sem detecção de AIT/SMS pumping nativa; custo de fraude absorvido silenciosamente
- Questionável sob diretrizes de autenticação forte do Banco Central
Inaceitável como status quo para CIAM financeiro em 2026
Opção B: TOTP/Authenticator App como segundo fator
- Suporte nativo no Cognito (software token MFA)
- Resistente a SIM swap e SS7
- Custo por verificação próximo de zero após setup
- Fricção de onboarding alta, requer instalação e vinculação de app
- Taxa de adoção tipicamente 15–30% em bases de usuários B2C
- Não resolve o problema de recuperação de conta quando o dispositivo é perdido
- Sem sinal de rede, não detecta SIM swap em tempo real
Adequado como opção opt-in para usuários de alto valor, não como substituto universal
Opção C: Silent Authentication via Vonage + Cognito CUSTOM_AUTH (proposta)
- Zero fricção para o usuário final em dispositivos móveis com dados celulares
- Prova de posse baseada em sessão celular, imune a phishing e SS7
- Pre-checks de Identity Insights bloqueiam fraude antes de custos de SMS serem incorridos
- Fallback automático para SMS/RCS/Voice quando dados celulares indisponíveis
- Fraud Defender mitiga AIT/SMS pumping em tempo real
- Dependência de terceiro (Vonage/Ericsson) no caminho crítico de autenticação
- Cobertura de MNO varia por região, requer validação por mercado
- Complexidade adicional no CUSTOM_AUTH Lambda trigger (Define, Create, Verify)
- Custo por verificação maior que SMS puro, mas compensado pela redução de fraude e suporte
Decisão recomendada para fluxos mobile-first em mercados com boa cobertura MNO
Opção D: Passkeys/WebAuthn como substituto de longo prazo
- Resistência phishing por design; sem segredo transmissível
- Suporte crescente em plataformas iOS e Android
- Custo por autenticação próximo de zero
- Suporte do Cognito ainda limitado, requer implementação customizada
- Recuperação de conta complexa quando dispositivo é perdido
- Adoção de usuário ainda em curva de aprendizado em mercados emergentes
Horizonte de 18–24 meses; não resolve o problema imediato de fraude
A Decisão: CUSTOM_AUTH como Superfície de Extensão Arquitetural
A decisão é adotar a Opção C como fluxo primário para autenticação mobile, com a Opção B como camada opt-in para usuários de alto valor e a Opção D como roadmap de 18 meses. O mecanismo técnico central é o fluxo CUSTOM_AUTH do Amazon Cognito, que expõe três pontos de extensão via Lambda triggers: DefineAuthChallenge, CreateAuthChallenge e VerifyAuthChallengeResponse.
O que torna o CUSTOM_AUTH adequado aqui não é apenas a flexibilidade, é a semântica correta. O fluxo foi projetado para desafios de autenticação externos, e a Silent Authentication é exatamente isso: um desafio resolvido por um terceiro (o MNO via Vonage) em vez de pelo usuário diretamente. O Cognito gerencia o ciclo de vida da sessão, emite tokens JWT com os claims corretos e mantém o audit trail, enquanto a lógica de verificação vive nos Lambdas.
Configuração crítica dos Lambdas: O CreateAuthChallenge Lambda é onde a chamada à API de Identity Insights da Vonage acontece. Este Lambda deve ter um timeout configurado para no mínimo 10 segundos (o padrão de 3s é insuficiente), usar uma VPC com NAT Gateway para chamadas de saída se a política de segurança exigir, e armazenar as credenciais da API Vonage no AWS Secrets Manager com rotação automática habilitada, nunca em variáveis de ambiente. O VerifyAuthChallengeResponse Lambda recebe o resultado da Silent Authentication e deve implementar idempotência via DynamoDB com TTL de 5 minutos para evitar replay attacks no token de verificação.
IAM e isolamento: Cada Lambda trigger deve ter uma role IAM separada com permissões mínimas. O CreateAuthChallenge precisa de secretsmanager:GetSecretValue escoped ao ARN específico do segredo Vonage. Nenhum dos triggers deve ter permissões de escrita no User Pool, apenas cognito-idp:RespondToAuthChallenge via o SDK do Cognito chamado pelo cliente.
Fluxo de Autenticação Silenciosa: Cognito CUSTOM_AUTH + Vonage
Fluxo completo desde a tentativa de login mobile até a emissão de tokens JWT, mostrando os três Lambda triggers do CUSTOM_AUTH, as chamadas à API Vonage e os pontos de decisão de risco.
- App Mobile · iOS / Android
- Amazon Cognito · CUSTOM_AUTH flow
- DefineAuthChallenge · Lambda
- CreateAuthChallenge · Lambda (timeout: 10s)
- VerifyAuthChallenge · Lambda
- Secrets Manager · Vonage API Key
- DynamoDB · Idempotency TTL 5min
- CloudWatch · SLO / Anomaly
- Identity Insights API · sim_swap / format / recycled
- Silent Auth / Verify · Cellular session proof
- Fraud Defender · AIT / SMS pumping block
- Operadora Móvel · Real-time SIM data
Consequências Técnicas: O Que Muda na Operação
Adotar o fluxo CUSTOM_AUTH com dependência de terceiro no caminho crítico de autenticação introduz consequências operacionais que precisam ser gerenciadas explicitamente.
Disponibilidade e fallback: O SLA do Vonage para a API de Verify é documentado, mas qualquer dependência externa em um fluxo de autenticação precisa ter um circuit breaker. Implementei isso no CreateAuthChallenge Lambda usando AWS Lambda Powertools com o decorator @circuit_breaker, configurado para abrir após 5 falhas consecutivas em uma janela de 60 segundos. Quando o circuit breaker está aberto, o Lambda retorna um desafio de fallback que instrui o Cognito a usar SMS OTP padrão via SNS, garantindo que nenhum usuário legítimo seja bloqueado por indisponibilidade do Vonage.
Observabilidade: O VerifyAuthChallengeResponse Lambda emite métricas customizadas para CloudWatch com as seguintes dimensões: AuthMethod (silent_auth | sms_fallback | blocked_fraud), RiskSignal (sim_swap_detected | clean | recycled_number), e Outcome (success | failure | challenge_expired). Isso permite criar um SLO de autenticação silenciosa separado do SLO de autenticação geral, crítico para identificar degradação de cobertura MNO por região.
Latência: A Silent Authentication adiciona ~800ms–1.2s de latência ao fluxo de autenticação em condições normais (consulta MNO em tempo real). Para o CreateAuthChallenge Lambda, configurei memória em 512MB, acima do mínimo, porque a chamada HTTP à API Vonage se beneficia de CPU adicional para TLS handshake. O timeout do Lambda em 10s é conservador; o p99 observado foi de 3.2s.
Custo: O custo incremental por autenticação bem-sucedida via Silent Auth é maior que SMS puro, mas o modelo de ROI muda quando você considera: (a) eliminação de 8–12% de AIT, (b) redução de ~60% em tickets de suporte OTP, e (c) recuperação de 2–5 pontos percentuais de conversão. Para 4M MAU com frequência de login de 3x/mês, a matemática favorece a migração.
Consequências e Riscos que Precisam de Mitigação Explícita
1. Cobertura MNO não é uniforme. A Silent Authentication requer que o dispositivo do usuário esteja em uma sessão de dados celulares ativa no momento da autenticação. Wi-Fi, VPN e alguns MVNOs podem impedir a verificação. Valide a cobertura por operadora e por país antes do rollout, não assuma que a cobertura do seu maior mercado representa os demais.
2. O CUSTOM_AUTH não suporta refresh token rotation nativo. Se você usa rotação de refresh token no Cognito, o fluxo CUSTOM_AUTH não herda esse comportamento automaticamente. Você precisará implementar a lógica de revogação de token explicitamente no DefineAuthChallenge Lambda, consultando uma tabela DynamoDB de tokens revogados.
3. Dependência de terceiro no caminho crítico. O Vonage/Ericsson é um parceiro AWS, mas ainda é um sistema externo. O circuit breaker é obrigatório, não opcional. Teste o fallback para SMS em seu runbook de gameday, não descubra que ele não funciona durante um incidente de produção.
4. Dados de rede móvel são dados pessoais sensíveis. Sob a LGPD, consultas de sim_swap e subscriber_match envolvem dados de telecomunicações que podem exigir base legal específica e registro no RIPD. Envolva o DPO antes do go-live.
Governança, Compliance e o Modelo de Ameaça Residual
Nenhuma decisão de autenticação elimina o risco, ela redistribui o modelo de ameaça. Com SMS OTP, o vetor primário é o atacante que controla o número de destino (SIM swap, SS7). Com Silent Authentication, o vetor residual é o atacante que compromete o dispositivo físico, o que é um bar significativamente mais alto, mas não zero.
O que o modelo de ameaça residual parece: Um atacante com acesso físico ao dispositivo desbloqueado pode completar uma Silent Authentication. Isso é verdade para qualquer mecanismo baseado em posse de dispositivo, incluindo TOTP e passkeys. A diferença é que Silent Authentication não tem um segredo que possa ser phished remotamente, o ataque requer presença física ou comprometimento do SO do dispositivo.
Integração com WAF e threat intelligence: O CreateAuthChallenge Lambda deve registrar o IP de origem, user-agent e características do dispositivo no CloudWatch Logs com structured logging (JSON). Um AWS WAF rule group no API Gateway que antecede o Cognito pode bloquear IPs com histórico de fraude antes que a requisição chegue ao fluxo CUSTOM_AUTH, reduzindo o custo de chamadas à API Vonage para tentativas claramente maliciosas.
Auditoria e não-repúdio: Cada autenticação bem-sucedida deve gerar um evento no CloudTrail com o AuthMethod usado. Para fins de compliance financeiro (PCI-DSS, SOC 2), o registro de qual mecanismo autenticou cada sessão é necessário para investigações de fraude. Configure o CloudTrail com S3 Object Lock em modo COMPLIANCE para garantir imutabilidade dos logs de autenticação por pelo menos 7 anos.
Política de risco escalonada: O resultado dos pre-checks do Identity Insights deve alimentar uma política de risco com três saídas: (1) clean → Silent Auth, (2) elevated risk (ex: sim_swap nos últimos 24h) → step-up com TOTP ou biometria, (3) high risk (ex: VoIP number + sim_swap recente) → hard block com notificação ao time de fraude. Essa política vive no DefineAuthChallenge Lambda e deve ser versionada como código.
Análise pelo AWS Well-Architected Framework
Segurança
O fluxo CUSTOM_AUTH com Identity Insights pré-verificação eleva o nível de assurance de autenticação. IAM roles separadas por Lambda trigger, credenciais no Secrets Manager com rotação, e KMS para criptografia de dados em repouso no DynamoDB de idempotência são requisitos não-negociáveis. O WAF na frente do Cognito adiciona defesa em profundidade.
Confiabilidade
O circuit breaker no CreateAuthChallenge Lambda com fallback para SMS OTP garante que a autenticação continue funcionando mesmo com indisponibilidade do Vonage. O SLO de autenticação deve ser monitorado separadamente por método (silent vs. fallback) para detectar degradação de cobertura MNO antes que afete usuários em escala.
Anti-Padrões a Evitar nesta Implementação
- Armazenar credenciais da API Vonage em variáveis de ambiente Lambda, use Secrets Manager com rotação automática e IAM condition
secretsmanager:ResourceTag/Service: vonage-auth - Implementar o CUSTOM_AUTH sem circuit breaker, qualquer latência ou indisponibilidade do Vonage se torna uma indisponibilidade de autenticação para todos os usuários mobile
- Usar um único Lambda para todos os três triggers do CUSTOM_AUTH, viola o princípio de responsabilidade única e torna o debugging de fluxos de autenticação exponencialmente mais difícil
- Não implementar idempotência no VerifyAuthChallengeResponse, tokens de verificação podem ser reutilizados em replay attacks se não houver TTL de invalidação
- Fazer rollout global sem validação de cobertura MNO por mercado, a taxa de fallback para SMS pode ser muito maior que o esperado em mercados com MVNOs dominantes
- Ignorar a dimensão de privacidade de dados, consultas de sim_swap e subscriber_match são dados de telecomunicações sensíveis que requerem base legal explícita sob LGPD/GDPR
Em implementações financeiras que fiz com CUSTOM_AUTH, o erro mais caro não foi técnico, foi não testar o fallback em produção antes do go-live. O circuit breaker funciona no ambiente de staging, mas o comportamento de fallback do Cognito quando o Lambda retorna um erro inesperado é diferente de quando ele retorna um desafio de fallback explícito. Teste os dois caminhos. Segundo ponto: a política de risco no DefineAuthChallenge precisa ser tratada como código de negócio crítico, não como glue code, versione, teste e faça code review com o time de fraude, não só com engenharia. A lição mais dura que aprendi é que a cobertura MNO que o vendor apresenta no deck de vendas é a cobertura de melhor caso; a cobertura real no seu mix de usuários pode ser 15–20 pontos percentuais menor, especialmente em mercados com alta penetração de MVNOs ou usuários em roaming.
Decisão Final e Recomendação
Para plataformas CIAM financeiras mobile-first com exposição a SIM swap, AIT e pressão de conversão, a migração de SMS OTP para Silent Authentication via Vonage + Cognito CUSTOM_AUTH é a decisão correta, mas com condições. Adote se: (a) sua base de usuários é predominantemente mobile com dados celulares, (b) você tem cobertura MNO validada nos seus mercados primários, (c) você implementa circuit breaker com fallback para SMS, e (d) você trata a política de risco no DefineAuthChallenge como código de negócio versionado. Não adote como substituto completo de SMS se sua base tem penetração significativa de Wi-Fi-only ou MVNOs sem cobertura de API. O modelo de ameaça residual é aceitável para o nível de assurance exigido por Open Finance e PCI-DSS nível 2. O ROI é positivo em 6–9 meses para bases acima de 1M MAU. Passkeys/WebAuthn é o destino de longo prazo, mas Silent Authentication é a melhor solução disponível hoje para o problema de autenticação mobile em escala financeira.
Referências
Continue lendo
Post-mortems, ADRs e deep dives de arquitetura no seu email, do jeito que um arquiteto lê.
Sem spam · cancele quando quiser
Pergunte ao Fernando sobre isto
Uma resposta focada sobre este estudo, do meu assistente de IA, baseada no meu trabalho.
Participe da conversa
Entre para comentar
Confirme seu e-mail para participar, você também recebe a newsletter. Sem senha.