Janelas de supressão de OTP por SMS: como reduzir reenvios duplicados sem bloquear utilizadores legítimos

O problema operacional: os reenvios não são uma simples função de UX

Quando uma pessoa pede várias vezes um código OTP por SMS, o sistema pode gerar códigos em simultâneo, aumentar o custo das mensagens, criar confusão sobre qual deve ser introduzido e ampliar a superfície de abuso. Também pode aumentar os contactos com o apoio ao cliente se o utilizador receber mensagens atrasadas ou se um código anterior deixar de funcionar sem uma explicação clara.

No entanto, suprimir rigidamente todos os pedidos repetidos também pode impedir uma autenticação legítima. O atraso pode estar na rede, no fornecedor de mensagens, no terminal ou na conectividade do utilizador. Além disso, há utilizadores que nem sempre podem depender de cobertura móvel e devem ter alternativas de autenticação autorizadas.

A janela de supressão de OTP por SMS é um controlo operacional que decide se um novo pedido deve ser aceite, adiado ou não deve gerar outro SMS. Não substitui os controlos de segurança do OTP: deve funcionar em conjunto com a validade limitada do segredo, a aceitação de utilização única, a limitação das tentativas de verificação e a avaliação de risco.

• Objetivo de segurança: limitar o abuso de pedidos e de tentativas de verificação.
• Objetivo operacional: evitar mensagens duplicadas e estados inconsistentes.
• Objetivo de experiência: informar sobre a espera sem revelar se existe uma conta ou um número.
• Objetivo de acessibilidade: disponibilizar métodos alternativos quando o SMS não puder ser utilizado.

O que uma janela de supressão controla

Uma janela de supressão não deve responder apenas à pergunta «quanto tempo passou desde o último clique?». Deve controlar uma decisão completa: se é criado um novo pedido, se é reutilizado um pedido ainda válido, se o envio é adiado, se uma tentativa pendente é cancelada ou se o utilizador é encaminhado para uma alternativa autorizada.

A decisão deve ser determinística no servidor. A interface pode mostrar uma contagem decrescente, mas não deve ter autoridade sobre quando um reenvio é permitido. O servidor mantém o estado do pedido, avalia limites e risco, emite o código e decide qual segredo pode ser verificado.

Convém definir explicitamente o comportamento dos códigos anteriores. Uma política frequente é invalidar os códigos anteriores quando é emitido um novo código para a mesma finalidade e pedido de autenticação. Se essa política for adotada, deve ser comunicada ao utilizador e aplicada de forma atómica para evitar que dois códigos fiquem válidos devido a uma condição de concorrência.

• Permitir: não existe um pedido válido que deva ser suprimido e os limites permitem o envio.
• Adiar: o pedido é legítimo, mas o período de arrefecimento do reenvio ainda está ativo.
• Suprimir: é detetada duplicação, uma operação equivalente já está em curso ou é ultrapassada uma restrição aplicável.
• Escalar ou mudar de canal: o risco, a acessibilidade ou uma falha técnica confirmada justificam uma rota alternativa autorizada.

Separar os três temporizadores essenciais

A validade do código, o período de arrefecimento do reenvio e a expiração do pedido são temporizadores distintos. Misturá-los tende a produzir dois erros: manter um código aceitável durante mais tempo do que o necessário ou negar um reenvio legítimo por confundir o tempo de espera com a validade criptográfica.

A validade do código define até quando o verificador pode aceitar o segredo. O NIST estabelece que a autenticação fora de banda deve ser concluída no prazo de 10 minutos e que o mesmo segredo só deve ser aceite uma vez durante o respetivo período de validade. Uma implementação pode escolher uma validade mais curta se a sua análise de risco e experiência do utilizador o justificarem.

O período de arrefecimento do reenvio define quanto tempo a pessoa deve esperar antes de pedir outro SMS. Trata-se de uma decisão operacional separada: deve reduzir cliques repetidos e tráfego duplicado, sem ser tratado como prova de que o primeiro SMS não chegará. A expiração do pedido determina quando a transação de autenticação é encerrada e é necessário iniciar um novo fluxo.

• Validade do código: controla a aceitação do segredo e a sua resistência à repetição.
• Período de arrefecimento do reenvio: controla a frequência de novos envios.
• Expiração do pedido: encerra o contexto transacional e evita estados indefinidos.
• Limite de tentativas de verificação: controla as tentativas falhadas e não deve ser reiniciado quando é emitido outro código.

Modelo de estados para um pedido de OTP

Modele o pedido de OTP como uma transação interna com um identificador único. Os estados do fornecedor de mensagens devem ser associados a essa transação, mas não devem controlar, por si só, a validade do código nem o resultado da autenticação.

Um modelo mínimo pode incluir criado, aceite, enviado, estado final comunicado, verificado, expirado e cancelado. O estado «estado final comunicado» representa que foi recebida uma atualização terminal do sistema de mensagens, mas não afirma que o utilizador tenha visto, lido ou utilizado o SMS.

As transições devem ser controladas pelo servidor e idempotentes. Por exemplo, uma verificação correta deve impedir a reutilização do segredo, mesmo que chegue posteriormente um callback de entrega atrasado. Da mesma forma, uma atualização externa fora de ordem não deve reabrir um pedido expirado, cancelado ou já verificado.

• Criado: existe o contexto de autenticação, mas o envio ainda não foi aceite.
• Aceite: as validações internas foram concluídas e foi decidido iniciar o envio.
• Enviado: o sistema registou a emissão para a conectividade de mensagens.
• Estado final comunicado: foi recebido um estado terminal externo, cuja semântica deve ser preservada sem sobreinterpretação.
• Verificado: o segredo válido foi devolvido e aceite uma única vez.
• Expirado ou cancelado: o pedido já não pode resultar numa autenticação correta.

Evidências para decidir um reenvio e limites dos DLR

A evidência mais forte para a autenticação é a verificação bem-sucedida do segredo dentro do respetivo período de validade. Um evento de transporte não substitui a resposta explícita do utilizador nem prova que o código foi recebido, lido ou introduzido no terminal.

Para decidir um reenvio, organize as evidências pela sua função. Os eventos internos indicam se já existe um pedido ativo, se um código continua válido, se ocorreu uma verificação ou se foram atingidos limites. A resposta de envio permite saber se o sistema de mensagens aceitou ou rejeitou a operação de acordo com a sua interface. Os DLR podem fornecer informação sobre o estado de entrega comunicado, mas a sua interpretação depende da semântica disponível na cadeia de mensagens.

Um DLR comunicado como entregue não deve ser tratado como confirmação independente de receção física, leitura ou posse legítima do terminal. Um DLR pendente também não prova uma falha. A política de supressão deve evitar tanto o reenvio imediato por ausência de DLR como o bloqueio automático por existir um DLR entregue.

• Utilize o estado interno para manter a autoridade da decisão.
• Conserve a resposta de envio e o seu identificador de correlação.
• Armazene o DLR original, o momento da sua receção e a relação com a mensagem.
• Não transforme um DLR em prova de leitura, identidade, consentimento ou sucesso de autenticação.
• Valide o OTP no servidor, mesmo que tenha sido comunicada uma entrega.

Regras práticas por cenário

No primeiro pedido, valide e normalize o destino de acordo com o enquadramento internacional de numeração aplicável, crie a transação, gere o segredo de curta duração e registe o evento antes de iniciar o envio. O resultado deve ser associado a identificadores de pedido, código e mensagem sem registar o segredo em texto simples.

Num reenvio antecipado, se existir um pedido ativo e o período de arrefecimento ainda não tiver terminado, não gere automaticamente outro código. Devolva uma resposta genérica que indique a espera aplicável e mantenha a possibilidade de introduzir o código atual. Se for permitido um reenvio após o fim do período de arrefecimento, aplique de forma atómica a política escolhida para o código anterior.

Quando o código tiver expirado, encerre o pedido anterior e crie um novo apenas se os limites e os sinais de risco o permitirem. Se a plataforma confirmar uma falha técnica antes de o envio ter sido aceite, pode ser definida uma exceção de nova tentativa; essa exceção deve ficar registada e não deve transformar-se num mecanismo ilimitado de geração.

Perante uma mudança de canal, não presuma que o SMS é adequado para todos os casos. A utilização da PSTN para autenticação fora de banda apresenta riscos que devem ser avaliados. Considere os sinais de risco disponíveis, como alterações de dispositivo, SIM ou portabilidade, e encaminhe para um autenticador alternativo autorizado quando a política o exigir.

• Primeiro pedido: criar contexto, registar, enviar e ativar temporizadores.
• Reenvio durante o período de arrefecimento: manter o código válido e mostrar o tempo de espera.
• Código expirado: encerrar o contexto anterior antes de emitir um novo.
• Falha técnica confirmada: aplicar uma exceção limitada, idempotente e auditável.
• Mudança de canal: preservar o contexto de risco e não reduzir os controlos de verificação.

DLR pendentes, rejeitados ou entregues: tratamento prudente

Um DLR pendente indica que ainda não existe uma atualização terminal disponível para essa operação. Não é uma razão suficiente para emitir imediatamente outro SMS. Mantenha a janela de arrefecimento e permita que o utilizador introduza o código enquanto este continuar válido.

Uma rejeição ou falha comunicada pode justificar uma política de nova tentativa controlada se for confirmado que o envio não foi aceite ou não avançou de acordo com os critérios internos definidos. Ainda assim, a nova tentativa deve estar sujeita a limites e a uma chave de idempotência para que as tentativas de rede não criem múltiplas mensagens.

Se for comunicada uma entrega, mantenha a regra de não equivalência: o sistema pode registar esse estado para análise operacional, mas não deve bloquear todas as alternativas nem concluir que o utilizador já dispõe do código. A autenticação só é concluída quando o verificador aceita o segredo válido devolvido pela pessoa.

• Pendente: aguardar, conservar o pedido e não inferir falha.
• Rejeitado: verificar o significado técnico do evento antes de tentar novamente.
• Entregue: registar como sinal de transporte, não como leitura ou autenticação.
• Fora de ordem: conservar o evento para diagnóstico sem fazer regredir o estado interno.
• Duplicado: aceitar o callback de forma idempotente e evitar efeitos repetidos.

Controlos de abuso sem bloquear utilizadores legítimos

A supressão de reenvios deve ser combinada com limites de pedido e limites de verificação. Os OTP curtos exigem a limitação de tentativas de verificação falhadas para reduzir a adivinhação online. A emissão de um novo código não deve reiniciar esse contador de falhas.

Não baseie o controlo apenas num endereço IP. A OWASP recomenda associar os contadores de falhas à conta e utilizar IP, dispositivo, localização, hora e comportamento como sinais complementares. Para pedidos de OTP, o número de destino, a conta, a sessão e o dispositivo podem fornecer contextos diferentes; nenhum deles deve ser considerado, por si só, prova de identidade.

Aplique medidas graduais em vez de uma única resposta binária. O NIST contempla esperas crescentes, deteção de bots e avaliação adaptativa como técnicas que podem complementar a limitação. Reveja os falsos positivos: viagens, redes partilhadas, dispositivos novos, cobertura limitada e necessidades de acessibilidade podem explicar comportamentos legítimos.

• Limites por conta: protegem o fluxo de autenticação associado.
• Limites por número: reduzem a pressão de envio para um destino específico.
• Limites por sessão e dispositivo: ajudam a detetar repetição automatizada no mesmo contexto.
• IP e outros sinais: fornecem contexto, mas não devem ser o único critério.
• Escalonamento gradual: espera, desafio adicional, alternativa autorizada ou revisão, conforme o risco.