Posse de e-mail e telefone: o que o OTP prova numa verificação de identidade
O que a confirmação de e-mail e telefone por código de uso único prova de fato num fluxo de KYC, onde esse sinal falha e em que ponto da jornada faz sentido pedi-lo.
Quase todo cadastro digital tem esse momento: chega um código de seis dígitos por e-mail ou por mensagem de texto, a pessoa digita na tela e o sistema marca o canal como verificado. O gesto é tão rotineiro que virou sinônimo de "verificar identidade" no vocabulário de muitas equipes. E aí mora uma confusão com consequência prática: o código de uso único (OTP, de one-time password) não prova identidade. Prova outra coisa, mais modesta e ainda assim valiosa.
Este texto é para quem desenha jornadas de KYC (Know Your Customer, conheça seu cliente): gente de produto, risco, engenharia e conformidade que precisa decidir se pede confirmação de e-mail, de telefone, dos dois ou de nenhum, e em que ponto do fluxo. A mecânica do código em si, geração, entrega e validação, já está descrita em como funciona a verificação por OTP em e-mail e telefone. Aqui o assunto é outro: o papel desse sinal dentro da jornada, o que ele prova, o que ele não prova e onde encaixá-lo sem atrapalhar o resto.
A única coisa que o OTP prova
Um código de uso único entregue por e-mail ou por SMS (Short Message Service, o serviço de mensagens de texto da rede celular) prova exatamente uma afirmação: quem está naquele fluxo, naquele momento, controla aquele canal. Nada além disso. Não diz quem a pessoa é, não diz se o nome informado pertence a alguém real, não diz se o rosto da selfie bate com a foto do documento.
Vale sublinhar as duas restrições embutidas na frase. Primeiro, "controla o canal" não é o mesmo que "é o dono legítimo do canal": um número obtido por golpe ou uma caixa de e-mail invadida passam no teste com a mesma facilidade que o titular verdadeiro. Segundo, "naquele momento" importa: a prova é instantânea e não se transfere para o futuro, porque o canal pode mudar de mãos amanhã.
Prova de identidade é outro processo, com outras ferramentas: documento oficial validado, biometria facial comparada com a foto do documento, prova de vida, checagem cadastral. A posse de canal não substitui nenhuma dessas etapas. Ela responde uma pergunta diferente, e é justamente por isso que complementa as demais em vez de competir com elas.
Por que um sinal modesto vale tanto
Se o OTP não prova identidade, por que quase toda jornada séria de verificação o inclui em algum ponto? Por três razões que não dependem de exagerar o que ele é.
Contato acionável. Um canal confirmado é um canal que alcança a pessoa de verdade. Isso sustenta tudo o que vem depois do cadastro: aviso de acesso suspeito, recuperação de conta, comunicação de mudança relevante. Um e-mail digitado errado, ou inventado só para passar pelo formulário, quebra essa corrente no primeiro elo. Confirmar cedo também expõe falhas silenciosas de entrega: o código que nunca chega é o sintoma mais visível dos problemas discutidos em entregabilidade de e-mail de verificação.
Custo real para o fraudador. Criar mil cadastros com e-mails aleatórios custa quase nada. Criar mil cadastros em que cada um exige receber e digitar um código obriga a manter caixas de e-mail funcionais e chips ativos em quantidade, ainda mais quando a operação também limita o reuso do mesmo canal. Isso custa dinheiro, exige logística e deixa rastro: chips comprados em lote, domínios recém-registrados, caixas criadas em sequência. A posse não impede a fraude industrializada, mas encarece cada unidade dela, e fraude é um negócio sensível a margem.
Matéria-prima para o antifraude. O canal confirmado carrega metadados que valem tanto quanto a confirmação: o domínio do e-mail é descartável ou tem histórico? O número foi portado há poucos dias? O mesmo telefone já apareceu em quantos cadastros nesta semana, e com que velocidade? Nenhum desses sinais decide nada sozinho, mas todos alimentam o motor de risco que escolhe se a jornada segue leve ou ganha etapas extras.
Os limites têm nome e sobrenome
Todo sinal tem modo de falha conhecido, e os do OTP estão documentados em fonte pública. O NIST SP 800-63B, publicação especial (Special Publication, SP) do National Institute of Standards and Technology (NIST), o instituto de padrões e tecnologia dos Estados Unidos, é a principal referência de autenticação digital do governo dos Estados Unidos, adotada como base por operações no mundo inteiro. Ela trata a entrega de códigos por canal separado como verificação fora de banda (out-of-band) e classifica o uso da rede telefônica, a PSTN (public switched telephone network), que engloba SMS e chamadas de voz, como canal restrito: quem usa SMS para autenticação precisa avaliar o risco dessa escolha e oferecer alternativa. O motivo central é a troca de chip: se o fraudador convence a operadora a transferir o número da vítima para um chip dele, todo código por SMS passa a chegar na mão errada. O ataque e as defesas possíveis estão detalhados em SIM swap e o limite do SMS.
O e-mail tem o equivalente: uma conta invadida entrega ao invasor todos os códigos enviados a ela. E como o e-mail costuma ser a âncora de recuperação de vários serviços, uma única conta comprometida derruba um dominó atrás do outro.
A consequência para a jornada de KYC é direta: ação de alto risco pede fator mais forte que posse de canal. Alterar dados bancários, movimentar valores altos, trocar o próprio canal cadastrado: nesses momentos, o desenho correto é re-verificação biométrica, comparando quem está na sessão com quem passou pela verificação original. Aplicativos autenticadores resolvem parte do problema por outro caminho: o TOTP (time-based one-time password), código de uso único por tempo definido na RFC 6238 (Request for Comments, o formato das especificações técnicas da internet), e seu antecessor por contador, o HOTP da RFC 4226, geram o código no próprio aparelho, sem rede de entrega, e por isso resistem à troca de chip. Mas continuam provando posse, agora do dispositivo cadastrado, e não identidade.
Onde encaixar a posse na jornada
Confirmar canal cedo demais adiciona atrito antes de o usuário enxergar valor: cada tela extra no topo do funil derruba conversão, e um código que demora dois minutos para chegar derruba ainda mais. Confirmar tarde demais cria o problema oposto: uma base de contas ativas sem nenhum canal confirmado, o que transforma qualquer incidente de segurança num exercício de adivinhar como avisar os clientes.
A boa prática é menos uma regra de posição e mais uma pergunta de desenho: o fluxo de negócio realmente usa esse canal? Se a recuperação de conta passa por e-mail, o e-mail precisa estar confirmado antes de a conta ter algo a perder. Se o produto nunca envia SMS, exigir posse de telefone no cadastro é atrito por hábito, não por função. E se o canal só passa a importar mais tarde, como na ativação de avisos de transação, a confirmação pode viver ali, onde o usuário entende por que ela está sendo pedida.
Essa lógica condicional explica por que plataformas de verificação tratam posse como peça avulsa. Na UNIFOKAL, por exemplo, a verificação de posse de e-mail e de telefone por código de uso único entra como etapa opcional do fluxo de verificação, cada uma como um módulo próprio que o cliente liga ou desliga conforme o caso de uso.
Detalhes de implementação que separam o bom do ruim
Decidido o papel e a posição do sinal, sobra a execução, e é nela que a maioria dos incidentes nasce. Quatro pontos concentram a diferença:
- Expiração curta. Código válido por horas é código esperando ser roubado. Minutos bastam para o uso legítimo: o usuário está com o aparelho na mão, no meio do fluxo.
- Limite de tentativas. Sem limite, um código numérico curto cai por força bruta. Poucas tentativas erradas devem invalidar o código e exigir a emissão de um novo.
- Reenvio com espera crescente. Reenvio imediato e ilimitado convida abuso: bombardeio de mensagens contra terceiros e custo de envio inflado. Cada novo pedido deve esperar mais que o anterior.
- Mensagem que nunca pede o código de volta. O golpe mais barato contra OTP não é técnico: é ligar para a vítima fingindo ser o suporte e pedir o código que acabou de chegar. A mensagem que entrega o código deve avisar, com todas as letras, que a empresa jamais o solicitará por telefone ou chat, e o atendimento precisa honrar essa promessa.
Nada disso muda o que o sinal prova. Muda quanto se pode confiar nele: um OTP bem implementado é uma prova de posse honesta; um OTP mal implementado é uma sensação de segurança com aparência de cadeado.