Rate limiting de OTP por SMS: limites por utilizador, número, IP e dispositivo sem prejudicar a autenticação

Porque o rate limiting de OTP é uma política operacional, e não apenas um controlo técnico

O rate limiting de OTP por SMS protege vários ativos em simultâneo: o fluxo de autenticação, o orçamento de mensagens, a capacidade operacional e a experiência de quem tenta aceder legitimamente. Uma política demasiado permissiva pode facilitar pedidos automatizados, inundar o canal SMS do destinatário e gerar tráfego artificial. Uma política demasiado rígida pode impedir acessos legítimos ou tornar-se numa via de negação de serviço contra contas específicas.

O objetivo não é bloquear indiscriminadamente o SMS. É decidir, de forma mensurável e passível de revisão, quando permitir um pedido, quando introduzir espera ou fricção adicional e quando restringir temporariamente uma ação de risco. A unidade de controlo deve corresponder à ação protegida e ao risco observado.

• Separar o abuso de pedidos da falha na introdução do código.
• Evitar que uma restrição baseada num único sinal, como o IP, determine sozinha o resultado.
• Medir o efeito de cada limite na segurança, conversão, reenvios e custo.
• Manter uma via de recuperação autorizada para quem não consiga concluir o fluxo habitual.

O que deve ser protegido num fluxo OTP por SMS

Um fluxo OTP contém ações distintas e estas não devem necessariamente partilhar a mesma quota. No mínimo, convém tratar separadamente o pedido inicial do código, o reenvio, a validação do código e a mudança para um canal alternativo ou de recuperação. Cada ação tem uma superfície de abuso diferente.

A validação do código exige uma proteção particularmente cuidadosa. Quando o segredo de autenticação é curto, o NIST exige um limite eficaz de tentativas falhadas consecutivas por conta e estabelece que a emissão de um novo código não deve reiniciar esse contador. O código deve ser de utilização única e o processo fora de banda deixa de ser válido se não for concluído no prazo de dez minutos.

O pedido ou o reenvio não devem, por si só, alterar o estado de uma conta. Um pedido repetido pode justificar uma espera, uma verificação adicional ou uma restrição temporária da ação, mas não deve produzir alterações sensíveis até ser apresentado um segredo válido.

• Pedido inicial: protege contra automatização e geração de tráfego SMS.
• Reenvio: evita duplicados, fadiga do destinatário e pressão artificial sobre o transporte.
• Validação: limita a adivinhação do código e deve manter o contador de falhas mesmo que seja emitido um novo código.
• Mudança de canal ou recuperação: requer regras próprias e uma avaliação de risco proporcional.

Limitar por várias entidades, e não apenas por endereço IP

Uma política baseada apenas em IP é insuficiente. Um atacante pode distribuir tentativas por múltiplos endereços, enquanto utilizadores legítimos podem partilhar a mesma saída de rede. A OWASP recomenda associar o contador de falhas à conta, em vez de depender exclusivamente do IP.

A prática mais útil é combinar dimensões. A conta ou identidade de início de sessão ajuda a proteger o processo de autenticação; o número MSISDN controla o destino do SMS; o IP acrescenta contexto de origem; o dispositivo, a sessão e a campanha ou aplicação permitem detetar concentração. Nenhum sinal deve ser interpretado como prova conclusiva por si só.

Antes de aplicar quotas por número, normalize o destino de forma consistente através de um esquema internacional de numeração, como o E.164. Sem normalização, variantes de representação do mesmo número podem fragmentar contadores ou produzir decisões incoerentes.

• Conta: essencial para limitar falhas consecutivas de validação e proteger contra força bruta distribuída.
• MSISDN normalizado: útil para controlar pedidos e reenvios direcionados ao mesmo destino.
• IP: sinal complementar para detetar volume, automatização ou concentração, e não a identidade do utilizador.
• Dispositivo: acrescenta contexto, mas deve ser utilizado com proporcionalidade porque pode ser partilhado.
• Sessão: permite associar pedidos e validações a um fluxo concreto.
• Campanha ou aplicação: ajuda a isolar problemas e a evitar que uma integração afete outras.

Como escolher janelas, quotas e períodos de espera

Não existe uma quota universal verificável que sirva para todos os serviços. Os limiares devem ser derivados do risco do caso de uso, da população esperada, da tolerância à fraude, da capacidade do serviço e do impacto de bloquear uma pessoa legítima. Devem ser documentados e revistos com dados próprios.

Uma janela fixa é fácil de explicar e auditar, mas pode concentrar pedidos junto dos seus limites. Uma janela deslizante oferece uma leitura mais contínua do comportamento recente, embora exija uma implementação e observabilidade mais cuidadosas. Um período de espera progressivo reduz a repetição imediata sem impor, desde o início, uma proibição longa.

A OWASP identifica três elementos que devem ficar explícitos: o número de falhas que ativa a restrição, o período em que são contadas e a duração da restrição. Também descreve o bloqueio exponencial, no qual a espera começa por ser curta e aumenta após falhas sucessivas.

• Utilize janelas simples quando a prioridade for a explicabilidade operacional e a auditoria.
• Utilize janelas deslizantes quando for importante evitar picos artificiais em torno de uma reposição temporal.
• Aplique períodos de espera progressivos a ações repetitivas antes de recorrer a bloqueios prolongados.
• Documente para cada regra: entidade, ação, limiar, janela, duração, exceção autorizada, responsável e condição de reversão.

Separar pedido, reenvio e validação evita controlos contraditórios

O pedido inicial e o reenvio consomem capacidade de mensagens; a validação consome capacidade de verificação e enfrenta o risco de adivinhação. Um único contador para todo o fluxo mistura causas e dificulta a investigação do que está a acontecer.

Uma implementação prudente pode manter um estado de desafio por sessão ou transação: destino normalizado, conta caso exista no fluxo, identificador de pedido, hora de emissão, expiração, estado de utilização, contador de validações falhadas e referências pseudonimizadas a sinais de risco. O segredo OTP não deve ser registado em texto simples.

A idempotência também é importante. Se o cliente repetir um pedido devido a uma resposta perdida ou a uma condição de rede, o serviço deve conseguir reconhecer a repetição num contexto controlado, em vez de gerar desnecessariamente várias mensagens. Esta decisão reduz duplicados e torna mais fiável a contagem de pedidos.

• Não reinicie as falhas de validação ao gerar um novo código.
• Marque o código como consumido após uma utilização válida para impedir reutilização.
• Indique ao utilizador quando pode pedir um novo envio, sem revelar informações sobre a conta.
• Conceba novas tentativas técnicas idempotentes para não as confundir com novos pedidos humanos.
• Isole as filas de envio da lógica de autorização: aceitar um pedido não equivale a confirmar a autenticação.

Respostas seguras e fricção progressiva

A resposta de um endpoint OTP deve ser neutra quanto à existência, ao estado e ao possível bloqueio de uma conta. A OWASP recomenda mensagens consistentes e temporização uniforme para reduzir a enumeração através de diferenças de conteúdo ou tempo.

Quando um sinal de risco aumenta, é preferível aplicar fricção progressiva em vez de um bloqueio abrangente. Por exemplo, uma espera visível antes do reenvio, uma verificação adicional contra automatização ou uma revisão de risco podem ser medidas proporcionais. Um CAPTCHA pode atuar como defesa em profundidade e pode ser introduzido após algumas falhas, não necessariamente na primeira tentativa.

As restrições devem impedir o abuso sem permitir que um terceiro exclua utilizadores legítimos. Por isso, não é aconselhável aplicar uma suspensão prolongada de conta apenas porque alguém pediu repetidamente códigos para esse destino.

• Utilize mensagens como: “Se o fluxo for válido, receberá instruções ou poderá continuar quando o período de espera terminar”.
• Mostre uma contagem decrescente de reenvio associada à transação, e não informação sobre a existência de uma conta.
• Aumente a fricção consoante a repetição, velocidade e concentração de sinais, e não por uma única observação isolada.
• Reserve restrições de maior impacto para risco corroborado e durante uma duração definida.
• Disponibilize recuperação autorizada quando o canal habitual não for viável.

Sinais que justificam rever ou reforçar controlos

Os sinais de risco servem para priorizar a revisão e ajustar controlos; não equivalem, por si só, a uma identidade ou a uma prova de fraude. A OWASP recomenda tratar como não confiáveis os dados recebidos de clientes, dispositivos, redes ou serviços externos, porque podem estar em falta, repetir-se, ser modificados ou falsificados.

Procure padrões de concentração e repetição: muitos pedidos para o mesmo destino, atividade rápida a partir de uma origem, sequências de reenvio sem validação, falhas persistentes de código ou volume anómalo dentro da mesma aplicação. Em canais PSTN, o NIST recomenda considerar indicadores como mudança de dispositivo, mudança de SIM, portabilidade do número ou outro comportamento anómalo antes de enviar o segredo.

O dispositivo exige um tratamento especialmente prudente. Pode fornecer um sinal útil perante abuso em grande escala, mas os dispositivos também são partilhados. Não transforme uma associação de dispositivo numa proibição automática de acesso para vários utilizadores legítimos.

• Concentração: repetição numa conta, número, sessão ou aplicação.
• Velocidade: cadência incompatível com a utilização normal esperada do fluxo.
• Padrão de falha: múltiplas validações incorretas ou pedidos sem conclusão.
• Destino: alterações invulgares no padrão de destinos dentro de uma aplicação.
• Risco contextual: indicadores de mudança de dispositivo, SIM ou portabilidade, tratados como sinais e não como certezas.
• Qualidade do sinal: dados incompletos ou não confiáveis devem reduzir a confiança na decisão, e não agravá-la automaticamente.

O que registar sem armazenar mais dados do que o necessário

Os registos permitem explicar uma decisão, investigar abusos e detetar falsos positivos. A OWASP recomenda registar sucessos e falhas de autenticação, tentativas de ultrapassar limites e atividade suspeita na lógica de negócio, utilizando uma taxonomia consistente e documentada.

Para cada evento, conserve o contexto de quando, onde, quem e o que aconteceu: marca temporal, identificador de interação, ação, resultado, regra aplicada e nível de confiança. Utilize identificadores pseudonimizados ou referências protegidas, quando adequado, para a conta, o número, o dispositivo ou a sessão.

Não registe segredos OTP, palavras-passe, tokens de acesso, valores de sessão ou dados pessoais desnecessários. Aplique mascaramento, hash, cifragem ou pseudonimização conforme o caso e assegure que os controlos de acesso aos registos são coerentes com a sensibilidade dos dados.

• ID de interação ou transação para correlacionar pedido, envio e validação.
• Marca temporal, ação, resultado e motivo da decisão.
• Identificador da regra, entidade limitada e estado da quota, evitando expor segredos.
• Referência pseudonimizada ao destino e a outros sinais necessários para correlação.
• Contexto técnico de origem apenas na medida necessária para segurança e investigação.
• Eventos de exceção, revisão manual e reversão para manter a rastreabilidade.