API de autenticação em dois fatores

A autenticação em dois fatores pede uma segunda prova independente ao lado da senha: algo que você sabe mais algo que você tem. A independência é o ponto inteiro. Um vazamento de base de senhas vale muito menos quando ele sozinho não abre conta nenhuma.

O segundo fator só ajuda na medida em que for genuinamente separado. Um código enviado para um e-mail protegido pela mesma senha não é um segundo fator; uma prova ligada a um aparelho físico é.

O SMS é o segundo fator mais difundido e o mais fraco ainda em uso comum. Códigos podem ser redirecionados por um SIM swap, obtidos por uma página convincente que simplesmente pede para lê-los em voz alta, e atrasados ou perdidos pelo roteamento da operadora. Cada envio também custa dinheiro, o que faz do login um lugar onde atacantes podem gastar o seu orçamento.

Nada disso torna a 2FA por SMS inútil — ela é enormemente melhor do que nenhum segundo fator. Significa apenas que, se você está escolhendo hoje, há pouca razão para escolhê-la como padrão.

Enviar o desafio pelo WhatsApp tira a operadora do caminho: a entrega é pela internet, a mensagem é criptografada de ponta a ponta e não há cobrança por SMS. Ela também chega num aplicativo que o usuário já tem aberto na maioria dos mercados.

Por si só, porém, isso resolve entrega e custo, não a fraqueza de fundo. Um código continua sendo um código, e um usuário capaz de ler um pode ser convencido a repeti-lo a um atacante.

O Reverse OTP muda o que é o segundo fator. Em vez de enviar um segredo ao aparelho e pedir que o usuário o repasse, ele pede que o aparelho envie uma mensagem. O usuário toca num link e envia; o servidor associa a mensagem recebida à sessão de login pendente.

Isso remove por completo o objeto passível de phishing. Não há código na tela para alguém ler em voz alta, nada em trânsito para interceptar e nada que um SIM swap possa redirecionar — a prova vem de uma conta de WhatsApp vinculada ao aparelho, não de um número que uma operadora pode reatribuir.

As chamadas são as mesmas duas do cadastro. Quando um login exigir um segundo fator, abra uma sessão com POST /start-verification usando um identificador ligado àquela tentativa de login e apresente o deep link devolvido. Mantenha a sessão aberta no servidor e conclua o login apenas quando GET /check-verification-status reportar verified.

Duas regras mantêm isso sólido. Vincule a sessão de verificação à tentativa de login, não ao usuário, para que uma sessão concluída nunca possa autorizar outra. E compare o número que a API devolve com o número guardado na conta — um número verificado que não é o daquele usuário é um segundo fator reprovado, não aprovado.

Ofereça SMS como alternativa onde o WhatsApp não estiver disponível, na mesma sessão, para que um usuário de um mercado de baixa adoção não fique travado. Além disso, planeje o caso em que o próprio aparelho sumiu: um segundo fator sem caminho de recuperação é uma indisponibilidade em preparação, e usuários que perdem o acesso costumam perder a conta junto.

Códigos de recuperação emitidos no cadastro do fator são a resposta habitual. Seja qual for a escolha, decida antes do lançamento — recuperação desenhada durante um incidente é sempre pior.

Para produtos de consumo, segundos fatores por telefone têm uma vantagem decisiva: o usuário já tem o aparelho e não precisa cadastrar nada. É por isso que a adoção deles é muito maior do que a de aplicativos autenticadores ou chaves físicas.

Para contas que protegem valor sério — acesso administrativo, controle financeiro, infraestrutura — uma chave de segurança física continua sendo a escolha mais forte, e as duas combinam bem. Use verificação por telefone onde importa abrangência e chaves onde importa profundidade.