Entrega e fraude de OTP
Onde uma senha de uso único vaza, o que um recibo de entrega pode e não pode dizer, e os controles e métricas que mantêm um fluxo de OTP.
Uma senha de uso único prova o controle de um número no momento em que é digitada. Não prova identidade, e um recibo de entrega não prova que uma pessoa leu o código. A entrega, a interceptação, a reciclagem do número e o próprio formulário decidem se a verificação se sustenta.
Fatos-chave
- Um OTP prova o controle de um número naquele momento, não a identidade.
- Um recibo de entrega informa um estado de rede, não que uma pessoa leu o código.
- Reciclagem de números, troca de SIM, desvio e phishing são as principais formas de vazamento.
- Limites de taxa, registro do remetente e checagens do número reduzem o abuso; nenhum prova identidade.
Nesta página
O que um OTP prova
Um OTP responde a uma pergunta: a pessoa à sua frente consegue receber uma mensagem neste número agora? Isso serve para recuperar conta e fazer login, porque liga a sessão a algo que o usuário controla. Não é um documento de identidade. O número pode ser reciclado, migrar para outro SIM, ser desviado ou ser lido por outra pessoa da casa.
A distinção importa na hora de desenhar o fluxo. Se a ação é de baixo valor, um OTP é proporcional. Se move dinheiro, troca senha ou adiciona um beneficiário, combine o código com uma segunda checagem: uma espera, uma confirmação em uma sessão existente, uma ligação para um canal conhecido ou uma revisão manual. O código é um fator, não a decisão inteira.
O caminho e os pontos onde um código vaza
- Aplicação
- Gateway SMPP
- SMSC
- HLR / HSS
- MSC / MME
- Celular
- Recibo de entrega
Descrição em texto
A aplicação envia o código a um gateway, a central de mensagens consulta o assinante e a central que o atende entrega ao celular. Um recibo volta pela mesma cadeia. O código pode vazar na aplicação, no celular, no próprio número ou pela pessoa que o recebe. O caminho de rede explica a entrega; não explica a pessoa que compartilha o código.
Onde um OTP vaza
Uma troca de SIM leva o número para um cartão novo. O atacante convence uma loja ou uma linha de suporte de que é o titular, e o próximo código vai para o SIM novo. A reciclagem de números faz o mesmo sem atacante: a operadora reatribui um número inativo e o novo titular recebe um código destinado à conta anterior. Os dois são motivos para checar se o número foi portado ou reatribuído há pouco tempo.
O desvio e a caixa de voz para texto mandam a mensagem para outra caixa. O phishing copia o formulário e coleta o código direto, então a rede nunca vê um ataque. A interceptação no caminho de rede é mais rara e fica fora do controle da aplicação; a resposta prática é um segundo fator, não um código mais longo. Leia a entrada de OTP do glossário para as definições.
Controles que ajudam
Limite a frequência com que um número, um endereço IP e um dispositivo podem pedir um código. Use validade curta, um único uso por código e amarre o código à sessão que o pediu. Registre o remetente e mantenha o conteúdo sóbrio: um código que parece marketing pode ser filtrado, e um código filtrado gera um ticket de suporte, não um login.
Cheque o número antes de confiar nele. Um número que não recebe SMS, que foi portado há pouco ou que tem histórico de redefinições merece um passo extra. Para ações de alto valor, exija uma sessão existente ou um segundo canal. Registre a requisição, o envio, o recibo e a digitação do código como eventos separados, para distinguir um problema de entrega de um problema do usuário.
Desenhe o código com o mesmo cuidado. Gere-o de uma fonte criptográfica, guarde um hash, faça-o expirar em minutos, permita um único uso correto e limite as tentativas por código e por sessão. Não revele se o número existe. Crie o registro da conta antes do envio, para uma retentativa não abrir uma conta que nunca se completa.
Cinco métricas, com definições
| Métrica | Definição | O que ela diz |
|---|---|---|
| Taxa de entrega | Recibos de entregue divididos por mensagens enviadas | Se a rede aceitou a mensagem; não se uma pessoa a leu |
| Taxa de conclusão | Códigos digitados divididos por mensagens entregues | Se a mensagem e o formulário funcionaram para o usuário |
| Tempo de entrega | Mediana e percentil 95 do envio ao recibo | Se a rota é lenta e quanto o usuário espera antes de reenviar |
| Taxa de reenvio | Reenvios divididos por mensagens entregues | Se os usuários esperam demais, erram a digitação ou nunca veem a primeira mensagem |
| Taxa de bloqueio | Requisições recusadas por regras de risco divididas pelas tentativas | Se as regras estão apertadas demais, frouxas demais ou o tráfego é abusivo |
Acompanhe por mercado, remetente e rota. Uma média global esconde a rota que está falhando.
Meça o fluxo, não o envio
Um envio que devolve um message ID não é um código entregue. Um código entregue não é um login concluído. Monte o funil com os eventos que você controla: envio, recibo, digitação do código, sucesso. Compare com a visão do provedor. Uma diferença entre a sua taxa de entrega e a dele pode ser um recibo que nunca chegou ao seu handler, não uma mensagem que nunca chegou ao celular.
Revise o fluxo quando uma métrica se move. Queda na conclusão com entrega estável aponta para o formulário, a expiração do código ou o remetente. Queda na entrega com envio estável aponta para a rota, o número ou o filtro de conteúdo. Alta no reenvio aponta para o tempo de entrega. Corrija o passo que os dados nomeiam, não o mais fácil de mudar.
Marque uma data de revisão para o fluxo inteiro. Números mudam de mãos, rotas mudam e modelos envelhecem. Um fluxo que funcionava no lançamento pode falhar em silêncio seis meses depois, com o mesmo código e o mesmo provedor.
Confira o que aprendeu
-
Um usuário encaminha o código a um amigo. O código ainda prova identidade?
Não. Ele prova que o número podia receber o código naquele momento. Qualquer pessoa com o código pode usá-lo.
-
Um recibo diz entregue, mas o usuário nunca vê o código. O que verificar?
O estado do celular, o aplicativo de mensagens e o filtro de spam, o remetente e a rota. Um recibo de entregue é o estado da rede, não a tela do celular.
-
Por que a taxa de conclusão é mais útil que a de entrega?
A entrega para na rede. A conclusão inclui o usuário, a expiração do código e o formulário, que é onde a maioria das falhas aparece.
As respostas aparecem sob demanda. Nada é pontuado, armazenado ou enviado.
Perguntas frequentes
Um OTP é a mesma coisa que autenticação de dois fatores?
Códigos mais longos são mais seguros?
Um recibo de entrega prova que o usuário leu o código?
Devemos reenviar automaticamente?
O que devemos registrar?
Os recibos dizem entregue, mas os usuários não recebem nada. O que devemos verificar antes de trocar de provedor?
Termos que você encontrará
Relacionado
- Conectar por SMPP e HTTP
Levar uma rota de teste à produção sem quebrar binds, janelas ou recibos: estado do bind, taxa, keep-alive, codificação, callbacks e falhas.
- Pacote de modelos de RFQ e RFP
Listas de campos para solicitações de SMS no atacado, eSIM e dados, IoT e conectividade com a China, com checklist online.
- Relatório de exemplo de teste de rota
Exemplo estático anonimizado de um relatório de teste de rota: o que um teste de rota verifica, como ler as falhas e o que aciona uma revisão.
Produtos relacionados
Coloque em prática
Informe o tráfego, o destino e a medição necessária; respondemos com o próximo passo.