Orçamento de latência para OTP por SMS: como definir a expiração e os objetivos sem depender da média
Aprenda a decompor, medir e gerir a latência de um OTP por SMS com percentis, segmentação e sinais funcionais, sem confundir aceitação, DLR e utilização real do código.
Que problema um orçamento de latência resolve num fluxo de OTP por SMS
Um orçamento de latência para OTP por SMS transforma uma expectativa imprecisa — «o código deve chegar rapidamente» — num modelo operacional mensurável. A sua função é separar as etapas do percurso, atribuir responsabilidades, escolher sinais observáveis e decidir durante quanto tempo um código permanece válido sem se basear numa média global de entrega.
Num fluxo de autenticação fora de banda, o verificador gera um segredo temporário, envia-o por um canal secundário, como SMS, e a pessoa utilizadora devolve-o pelo canal primário. Por isso, o percurso relevante não termina quando uma plataforma aceita o pedido de envio, nem necessariamente quando chega um relatório de entrega: termina quando o verificador aceita uma apresentação válida do OTP.
O orçamento ajuda a tomar decisões de produto e operação: definir uma expiração razoável, estabelecer quando apresentar a opção de reenvio, detetar degradação por destino ou rota e evitar atribuir à rede móvel um atraso originado na aplicação ou numa fila interna.
- Defina o resultado funcional como a validação bem-sucedida do OTP, e não apenas como o envio da mensagem.
- Modele as etapas separadamente antes de definir qualquer objetivo de tempo.
- Meça por segmentos operacionais; um valor global pode ocultar degradações concentradas.
- Mantenha a segurança como uma restrição de conceção: o código deve ser temporário e aceite uma única vez.
Porque a latência média não serve para definir a expiração de um código
A média responde mal a uma questão crítica de produto: quanto tempo a grande maioria dos utilizadores legítimos precisa para concluir o fluxo. Um conjunto de entregas rápidas pode reduzir a média, mesmo que exista uma cauda significativa de experiências lentas. Se a expiração for definida com essa média, os casos na cauda expiram repetidamente, apesar de o indicador agregado parecer saudável.
A expiração também não representa apenas o transporte do SMS. Deve abranger o tempo desde a criação do segredo até à sua introdução e validação, incluindo o processamento interno, a transmissão, um possível atraso de rede, a disponibilidade do terminal e o tempo da pessoa utilizadora para ler e introduzir o código.
O NIST indica que, em OTP baseados em tempo, a duração de validade deve considerar o desvio de relógio esperado, uma tolerância para o atraso de rede e o tempo de introdução pelo utilizador. Este princípio evita conceber uma expiração com uma única medição de latência de fornecedor ou rota.
- Não utilize a média como critério principal de expiração nem como único SLO.
- Observe percentis elevados do tempo até à validação, juntamente com taxas de sucesso e expiração.
- Analise janelas temporais comparáveis, e não apenas agregados históricos.
- Diferencie um atraso de transporte de uma validação tardia causada pela interação da pessoa utilizadora.
Definições operacionais e marcas temporais mínimas
Antes de medir, defina cada evento com precisão e registe a respetiva marca temporal. Definições ambíguas geram comparações inválidas entre equipas, fornecedores ou destinos. Utilize um identificador de correlação interno para a tentativa de autenticação e um identificador de mensagem para o envio, mantendo os dados de correlação não sensíveis.
Uma sequência prática começa com a criação do OTP e a sua associação à transação de autenticação. Em seguida, regista o pedido ao canal de envio, a aceitação desse pedido por API ou SMPP, os eventos disponíveis de colocação em fila e envio, qualquer DLR recebido e, por fim, a validação correta ou incorreta do código.
A aceitação por API ou SMPP apenas comprova que o fornecedor recebeu corretamente o comando ou pedido. Não comprova que o SMS chegou ao dispositivo. Da mesma forma, um DLR é um sinal assíncrono cujo significado depende do relatório recebido e da cadeia de entrega; deve ser conservado como evidência operacional, sem o tratar como prova de leitura nem como relógio definitivo de entrega.
- t0: criação do OTP e abertura do seu período de validade.
- t1: pedido de envio emitido pela aplicação.
- t2: aceitação por API ou SMPP e atribuição do identificador de mensagem, quando existir.
- t3: eventos de envio ou de alteração de estado disponíveis na plataforma.
- t4: receção do DLR e, quando disponibilizadas, as marcas temporais e tentativas contidas no próprio relatório.
- t5: apresentação e validação bem-sucedida do OTP, ou registo de expiração, falha ou abandono.
Que partes cada interveniente controla
O emissor controla a conceção da experiência, a geração do código, a criação do pedido, o comportamento da aplicação, as suas próprias filas, as regras de expiração, os limites de tentativas e a instrumentação. Também pode escolher a conectividade disponível, definir políticas por destino e atuar sobre rotas de acordo com os seus acordos e controlos operacionais.
O fornecedor de mensagens e os intermediários controlam partes da aceitação, do tratamento e da entrega para as redes ligadas, conforme a arquitetura e os acordos aplicáveis. A rede móvel controla elementos do encaminhamento e da entrega reportada dentro do seu domínio. O terminal, a cobertura disponível, o estado do dispositivo e o comportamento da pessoa utilizadora estão fora do controlo direto do emissor.
Esta separação deve refletir-se no diagnóstico. Se aumentar o tempo entre a criação e a aceitação, investigue primeiro a aplicação ou a conectividade de saída. Se a aceitação se mantiver estável, mas a distribuição de DLR ou validações mudar para um destino, investigue o segmento afetado sem concluir que um único evento prova a causa.
- Aplicação: geração, armazenamento seguro, expiração, UI, pedido e validação.
- Conectividade de envio: aceitação, resposta técnica e identificadores de mensagem.
- Rota e rede móvel: tratamento da entrega e sinais de estado que possam ser reportados.
- Terminal e utilizador: disponibilidade prática do código, leitura e introdução.
- Verificador: decisão final de aceitar ou rejeitar o OTP apresentado.
Como construir um orçamento de latência por etapas
Construa o orçamento a partir do resultado que importa: uma validação válida antes de expirar. Comece por reunir eventos de tentativas reais de autenticação, com correlação entre a tentativa, a mensagem e o resultado da verificação. Exclua da definição os eventos que não possam ser associados de forma fiável, mas quantifique essa falta de correlação como uma limitação de observabilidade.
Calcule distribuições para cada intervalo: criação até ao pedido, pedido até à aceitação, aceitação até qualquer sinal posterior disponível e criação até à validação bem-sucedida. Mantenha separados os casos validados, expirados, abandonados, falhados e aqueles em que o código estava incorreto. Misturá-los numa única série oculta problemas de segurança, UX e entrega.
O orçamento final não é uma promessa de que todas as mensagens serão concluídas num prazo fixo. É uma política: uma janela de validade acompanhada por limites de reenvio, controlos de tentativas, alternativas de autenticação quando aplicável e limiares operacionais por segmento.
- 1. Defina o evento de início: normalmente, a criação do OTP.
- 2. Defina o evento funcional de fim: validação bem-sucedida pelo verificador.
- 3. Registe intervalos intermédios com marcas temporais distinguíveis.
- 4. Classifique o desfecho de todas as tentativas.
- 5. Calcule percentis por segmento e janela temporal.
- 6. Defina a expiração considerando transporte, interação humana e requisitos de segurança.
- 7. Reveja a política após alterações de rota, produto, conectividade ou comportamento do tráfego.
Percentis, janelas temporais e segmentação por destino
Utilize percentis para descrever a distribuição, e não apenas um ponto central. Os percentis dos tempos até à validação ajudam a observar a experiência da parte mais lenta dos utilizadores que concluem o fluxo. Devem ser lidos juntamente com a proporção de tentativas que expiram, a taxa de validação e o volume, pois um percentil calculado sobre poucas observações pode ser instável.
Segmente, no mínimo, por destino. Quando os dados e o volume o permitirem, acrescente dimensões úteis para a operação: rota, remetente, tipo de número, tipo de tráfego, versão da aplicação ou política de risco. Não misture segmentos com comportamentos diferentes e espere depois que um único limiar global explique a causa de um desvio.
Compare cada segmento com a sua própria linha de base, em janelas temporais coerentes. Uma janela demasiado curta reage ao ruído; uma demasiado longa pode atrasar a deteção. Estabeleça também um volume mínimo de observações antes de tomar decisões automatizadas ou escalar um alerta.
- Meça o tempo da criação até à validação como métrica funcional principal.
- Meça da criação até à aceitação para isolar atrasos internos ou de conectividade.
- Conserve os DLR e as suas marcas temporais como telemetria complementar, e não como substituto da validação.
- Analise a percentagem de expirações, reenvios, tentativas falhadas e validações bem-sucedidas juntamente com os tempos.
- Exija volume suficiente antes de comparar percentis entre segmentos.
Expiração, reenvio, limites de pedidos e prevenção de duplicados
A janela de expiração deve ser suficientemente ampla para abranger a experiência legítima prevista, mas não deve tornar-se um substituto dos controlos de segurança. Para a autenticação fora de banda abrangida pelo NIST, a transação deve ser concluída no prazo de 10 minutos e um determinado segredo só pode ser aceite uma vez durante o seu período de validade. Aplique sempre os requisitos regulamentares, contratuais e de risco aplicáveis ao seu caso de utilização.
O reenvio não deve criar uma tempestade de mensagens nem alargar indefinidamente a superfície de ataque. Antes de emitir outro SMS, verifique se existe um OTP válido associado à mesma transação e decida explicitamente se é reutilizado, invalidado e substituído, ou se o pedido é limitado. A política deve ser consistente para que não existam vários códigos ambíguos ativos sem uma regra clara de validação.
Para segredos curtos, limite efetivamente as tentativas falhadas consecutivas. A emissão de um novo segredo não deve reiniciar o contador de falhas. Pode utilizar esperas progressivas e sinais de risco para reforçar o fluxo quando surgirem padrões anómalos, mantendo alternativas de autenticação quando o risco, a cobertura ou a acessibilidade o exigirem.
- Mantenha um único estado autoritativo por transação de autenticação.
- Faça com que cada OTP seja de utilização única.
- Defina uma política explícita sobre o que acontece ao OTP anterior após um reenvio.
- Limite os pedidos de reenvio por conta, sessão, destino e sinais de risco relevantes.
- Não reinicie os limites de tentativas falhadas ao emitir um novo código.
- Ofereça alternativas de autenticação quando SMS/PSTN não for adequado ou não estiver disponível.
O que um DLR pode indicar e o que não pode provar
Um DLR pode fornecer informação operacional útil: estado reportado, tentativas de entrega e, consoante a interface, marcas temporais da tentativa e da receção do relatório. É valioso para investigar tendências e para separar uma resposta técnica inicial de um estado de entrega comunicado posteriormente.
No entanto, o DLR não prova por si só que a pessoa utilizadora leu, compreendeu ou introduziu o código. Também não deve ser utilizado como o relógio para decidir imediatamente que existe um atraso de entrega. Os recibos ou eventos gerados pelos operadores podem chegar tarde; a documentação da AWS alerta que podem ser recebidos até 72 horas depois e que não devem ser utilizados para determinar um atraso de entrega de saída.
A validação bem-sucedida do OTP é um sinal funcional mais forte: demonstra que o código ficou disponível para a pessoa utilizadora e foi apresentado ao verificador. Ainda assim, isto não torna o DLR irrelevante; ambos os sinais respondem a perguntas diferentes e devem ser preservados separadamente.
- Aceitação de envio: o comando ou pedido foi recebido corretamente.
- DLR: resultado de entrega reportado de forma assíncrona, com incerteza de tempo e alcance.
- Validação bem-sucedida: evidência funcional de que o código foi apresentado corretamente ao verificador.
- Ausência de DLR: não deve ser interpretada automaticamente como ausência de entrega.
- DLR Delivered: não prova leitura nem introdução correta do código.
Perguntas frequentes
Que métrica deve orientar a expiração de um OTP por SMS?
A referência mais útil é a distribuição do tempo desde a criação do OTP até à sua validação bem-sucedida, segmentada por destino e outras dimensões operacionais relevantes. Deve ser complementada com taxas de expiração, reenvio e falha, e não com uma média de entrega isolada.
A aceitação por API ou SMPP significa que o SMS chegou ao telefone?
Não. Indica que o comando ou pedido foi recebido corretamente pelo sistema que o aceita. Não demonstra a receção no dispositivo de destino.
Um DLR Delivered prova que o utilizador recebeu e leu o OTP?
Não. Um DLR representa um resultado de entrega reportado e pode ser útil como sinal operacional, mas não prova leitura, compreensão nem introdução do código. A validação bem-sucedida é o sinal funcional mais forte.
Quanto tempo deve durar um OTP enviado por SMS?
Não existe uma duração universal que possa ser deduzida a partir de uma média de entrega. Defina-a com base na distribuição dos tempos até à validação, no tempo de interação esperado, no risco e nos requisitos aplicáveis. Para a autenticação fora de banda abrangida pelo NIST, a transação deve ser concluída no prazo de 10 minutos.
Deve gerar um novo código sempre que o utilizador pede um reenvio?
Deve existir uma política explícita. Se for gerado um novo código, defina o que acontece ao anterior para evitar ambiguidade e não reinicie os controlos de tentativas falhadas. Também é recomendável limitar os pedidos de reenvio e aplicar esperas ou medidas adaptativas quando apropriado.
Como detetar degradação numa rota de OTP?
Compare percentis de tempo até à validação, taxas de expiração, reenvios e sinais de entrega com uma linha de base própria, segmentando por destino, rota, remetente ou outras dimensões disponíveis. Exija volume suficiente e um desvio sustentado antes de atribuir um pico isolado a um problema de rota.
Fontes consultadas
- NIST SP 800-63B: autenticación fuera de banda y secretos temporalesNational Institute of Standards and Technology (NIST)
- AWS End User Messaging SMS User Guide: eventos, DLR y feedback de mensajesAmazon Web Services (AWS)
- Azure Communication Services SMS Delivery Reports APIMicrosoft
- Azure Communication Services: eventos SMSMicrosoft
- OWASP Authentication Cheat SheetOWASP Foundation