Adicionar MFA a um protótipo sem quebrar os logins

Por que o MFA quebra os logins de protótipos com tanta frequência

Adicionar MFA a um app protótipo não é “só mais uma tela”. Muda as regras sobre quem pode entrar, o que acontece quando algo dá errado e quantos casos de borda seu fluxo de login deve tratar.

Codebases de protótipo frequentemente têm autenticação frágil: sessões e tokens misturados, fonte de verdade do usuário pouco clara e atalhos como pular verificação de e‑mail ou reutilizar códigos de uso único. O MFA expõe esses atalhos rápido. Um pequeno desalinhamento (desvio de tempo do TOTP, registros de usuário duplicados ou uma corrida entre “verificar senha” e “criar sessão”) pode trancar usuários reais.

“Não quebrar logins” significa mais que “o caminho feliz funciona”. Pessoas ainda precisam entrar em dispositivos e navegadores antigos, precisa haver uma maneira segura de voltar se perderem o segundo fator, e sua carga de suporte não pode explodir com tickets “estou trancado”.

Antes de mudar qualquer coisa, meça sua linha de base para saber se o MFA ajudou ou prejudicou. Acompanhe alguns números por vários dias: taxa de sucesso de login, abandono por etapa (senha inserida, prompt de código mostrado, código aceito), eventos de bloqueio e conclusões de redefinição de senha, e tempo mediano para entrar.

Também decida quem você está protegendo primeiro. Forçar MFA em todos imediatamente maximiza atrito e suporte. Um ponto de partida mais seguro é contas de alto risco como admins, acesso a faturamento e qualquer pessoa que possa mudar configurações de segurança. Isso dá dados do mundo real sem transformar todo seu login num alarme.

Noções básicas de MFA e onde ele se encaixa no fluxo de login

MFA (autenticação multifator) significa provar que é realmente você com dois tipos diferentes de evidência. Normalmente isso é uma senha (algo que você sabe) mais um código ou aprovação de dispositivo (algo que você tem). O “segundo fator” é essa checagem extra. “Step‑up auth” significa pedir MFA apenas quando a ação é arriscada, como mudar um e‑mail ou ver faturamento. “Recuperação” é a saída caso você perca o fator.

O lugar mais seguro para encaixar o MFA em um protótipo é depois que a primeira etapa de login for bem-sucedida. Isso mantém seu fluxo de senha ou OAuth existente intacto.

Onde o MFA fica no fluxo

Para login por senha: o usuário insere e‑mail e senha, você os verifica e então checa se o MFA está habilitado. Se estiver, peça um TOTP ou confirmação por passkey antes de criar a sessão completa.

Para login via OAuth (Google, GitHub etc.): complete o callback do provedor, encontre ou crie o usuário e então exija MFA antes de emitir seu cookie de sessão ou token.

A ideia chave: não “meio logue” esperando recuperar se o MFA falhar. Decida exatamente quando o usuário está totalmente autenticado e faça do MFA parte dessa decisão.

O que muda no seu banco de dados

Mantenha os dados do MFA separados dos dados de senha e trate‑os como sensíveis.

Normalmente você precisa de uma flag simples de habilitado e timestamp de inscrição, o método escolhido (TOTP, passkey, nenhum) e metadados específicos do método, e o mínimo necessário para verificar desafios futuros (por exemplo, um segredo TOTP criptografado ou IDs de credenciais de passkey). Adicione hashes dos códigos de recuperação (não texto puro), um marcador “usado” por código e, opcionalmente, um campo como last_mfa_verified_at se planeja impor regras de step‑up.

O que logar para troubleshooting

Bons logs permitem depurar bloqueios sem vazar segredos. Registre eventos como “MFA challenge criado”, “verificação MFA falhou” e “código de recuperação usado”, mais ID do usuário, timestamp, IP e user agent. Não registre códigos TOTP, segredos, códigos de recuperação em texto puro ou tokens OAuth completos.

Escolhendo TOTP vs passkeys para um protótipo

Se você está adicionando MFA a um protótipo, a escolha costuma ser entre TOTP (códigos de autenticador) e passkeys (login por biometria ou dispositivo). Ambos funcionam, mas falham de maneiras diferentes.

TOTP é o clássico “digite um código de 6 dígitos”. Usuários escaneiam um QR com um app autenticador e depois inserem o código no login. Do seu lado, você armazena um segredo compartilhado por usuário (criptografado em repouso) mais alguns campos de auditoria como quando o MFA foi ativado e usado por último. Modos comuns de falha: usuário perde o telefone, horário do dispositivo fora de sincronia, inscrição duplicada que sobrescreve o segredo, ou seu app acidentalmente permite login sem checar o segundo fator.

Passkeys parecem mais simples. Usuários aprovam com Face ID, impressão digital ou PIN do dispositivo. Você armazena uma chave pública e um ID de credencial, não um segredo compartilhado. Os modos de falha mudam: dependência do dispositivo (sem acesso ao dispositivo), configuração confusa entre dispositivos, ou “funcionou no meu laptop mas não no meu celular” se as passkeys não sincronizarem como o usuário espera.

Uma regra prática é simples. Escolha TOTP quando precisar de acesso previsível entre dispositivos (admins, suporte, ferramentas B2B) e não puder assumir dispositivos modernos. Escolha passkeys quando quiser o login consumidor mais suave e puder aceitar que recuperação precise de cuidado extra. Dê suporte a ambos se seus usuários forem mistos, mas mantenha a UI focada: recomende um padrão (“Use passkeys neste dispositivo”) e ofereça o outro como fallback claro (“Use um app autenticador em vez disso”).

Exemplo: uma startup de duas pessoas enviando um painel admin interno pode escolher TOTP primeiro (funciona em todo lugar) e depois adicionar passkeys por conveniência sem mudar a política das contas admin.

Fluxo de inscrição que evita bloqueios

O maior risco na inscrição é habilitar o MFA cedo demais. Se você ativar a flag “MFA habilitado” antes do usuário provar que consegue usá‑lo, um fluxo de protótipo pode prendê‑lo num loop: “Digite código” sem um autenticador funcionando, prompt de passkey que nunca aparece ou sessão que some.

Um padrão seguro é tratar a inscrição como um teste e só habilitar o MFA após uma verificação bem-sucedida. Essa regra sozinha previne a maioria dos bloqueios.

Um padrão de inscrição à prova de bloqueio

Mantenha o fluxo linear e permissivo. Inicie a inscrição enquanto o usuário está totalmente logado (sessão fresca). Deixe‑o configurar o fator (escaneie QR TOTP ou crie um passkey) e então verifique imediatamente uma vez (insira um código TOTP ou complete a aprovação do passkey). Logo em seguida, mostre os códigos de recuperação e exija uma confirmação explícita como “Eu salvei eles.” Só então marque o MFA como habilitado e mostre uma tela clara de sucesso.

Boa redação reduz tickets. Seja específico: “Escaneie este QR no Google Authenticator ou 1Password. Depois insira o código de 6 dígitos para confirmar. Se fechar esta aba antes de confirmar, o MFA NÃO será ativado.”

Casos de borda a tratar desde o início

TOTP frequentemente falha por causa de drift de tempo. Se um código for rejeitado, diga aos usuários para checar se a hora do telefone está automática e permita uma segunda tentativa antes de forçar um reinício.

Passkeys podem falhar quando o dispositivo está ausente ou o prompt é bloqueado. Ofereça caminho alternativo durante a inscrição: “Não consegue usar passkey agora? Use um app autenticador.” Garanta que códigos de recuperação funcionem mesmo se o dispositivo de passkey for perdido.

Códigos de recuperação: configuração, armazenamento e regeneração

Códigos de recuperação são a opção “quebrar o vidro” quando o MFA falha: telefone perdido, app autenticador apagado ou passkey indisponível. São chaves reservas, não um método cotidiano. Mostre‑as logo após a inscrição bem-sucedida e deixe claro que esse é o momento de salvá‑las.

Mantenha o conjunto pequeno o suficiente para que as pessoas realmente o guardem. Dez códigos de uso único é um ponto comum para protótipos porque cobre alguns dias ruins sem virar uma lista longa que o usuário ignora. Use linguagem simples como “Salve isto agora. Você não poderá vê‑los novamente.” Ofereça copiar e baixar, mas exija uma verificação forte (senha ou MFA atual) antes de mostrar ou regenerar códigos.

O maior erro é armazenar códigos de recuperação em texto claro. Armazene apenas versões hashed (como senhas) e mantenha um registro claro de usado vs não usado para que cada código funcione uma vez e então expire.

Um modelo de armazenamento seguro é direto: gere 8–10 códigos aleatórios, armazene cada código como hash mais um used_at timestamp (nulo até usado), limite requisições e bloqueie temporariamente o formulário de recuperação após tentativas repetidas, e registre o uso de código de recuperação como evento de segurança.

A regeneração deve ser rigorosa. Quando um usuário gera novos códigos de recuperação, invalide todos os antigos imediatamente, mesmo os não usados. Avise claramente: “Seus códigos de recuperação anteriores deixarão de funcionar agora.” Para mais segurança, permita regeneração apenas após uma verificação forte (MFA atual ou login verificado recentemente), assim alguém com senha roubada não substitui silenciosamente os códigos.

Implementar MFA em fases com caminhos de fallback claros

Tentar impor MFA num grande interruptor geralmente cria uma onda de bloqueios. Um rollout em fases reduz risco e mostra onde usuários reais ficam presos.

Um plano em fases para a maioria dos apps pequenos:

• Opt‑in: solicite que usuários habilitem MFA após login, com opção clara de pular.
• Obrigatório para admins e equipe: proteja as contas de maior risco primeiro.
• Obrigatório para todos: somente depois que inscrição e recuperação estiverem estáveis e sem surpresas.
• Step‑up apenas: use MFA só para ações arriscadas (mudar e‑mail, exportar dados, ver faturamento), mesmo que o login continue só por senha.

Cada fase precisa de um fallback seguro, ou o suporte será inundado. Mire em pelo menos duas formas de voltar: uma opção self‑serve e uma opção humana.

Caminhos de fallback que previnem bloqueios

Planeje isso antes de forçar qualquer coisa. Códigos de recuperação são o mínimo. Um fator de backup ajuda também (TOTP mais um passkey, ou dois passkeys). Se oferecer resets assistidos por suporte, defina checagens de identidade claras e um cooldown antes de remover o MFA. Um período de graça curto após a inscrição pode reduzir falsos bloqueios, mas mantenha isso bem limitado (por exemplo, “pular uma vez”) para que não vire uma brecha permanente.

Feature flags e comunicação

Use uma feature flag para liberar primeiro para contas internas, depois para pequenos cohorts (5%, 20%, 50%). Observe taxa de conclusão de inscrição, taxa de falha nos desafios MFA e tickets “não consigo acessar conta”.

Diga aos usuários o que vai mudar e o que fazer se perderem acesso. Uma mensagem curta no app vence um anúncio longo: “Você será solicitado por um código extra na próxima semana. Salve seus códigos de recuperação agora.”

Faça resets e mudanças de conta seguros para MFA

A maneira mais fácil de driblar o MFA é contornar por mudanças de conta. Trate resets e edições de perfil como eventos de segurança, não como simples formulários.

Redefinição de senha não deve desativar o MFA

Redefinições de senha favorecem atacantes porque caixas de entrada são comprometidas. Após um reset bem‑sucedido, mantenha o MFA ligado e exija um check de step‑up no próximo login. Se permitir resetar o MFA, torne‑o uma ação separada que exige um desafio MFA (ou código de recuperação) depois que a nova senha for definida.

Uma boa regra: mudar a senha pode ajudar alguém a retomar acesso, mas não deve dar o poder de remover o MFA.

Proteja mudanças de alto risco com step‑up

Algumas mudanças devem sempre exigir “prove que é realmente você”, como mudança de e‑mail, novo dispositivo de autenticação, remoção/substituição de MFA, mudança de número de telefone (se usar SMS como backup) e atualizações de dados de pagamento.

Se um usuário atualiza o e‑mail, envie confirmação ao e‑mail antigo e mantenha o antigo ativo até confirmação. Se o e‑mail antigo não for acessível, exija códigos de recuperação e uma revisão curta pelo suporte.

Sessões, dispositivos lembrados e tokens

“Lembrar este dispositivo” é aceitável, mas mantenha limites. Defina prazos claros (geralmente 14–30 dias), exija reautenticação para ações arriscadas mesmo em dispositivos lembrados e torne a revogação previsível: logout global após mudança de senha, rechecagem ou revogação de sessões quando MFA é habilitado ou substituído, e uma lista simples de “sessões ativas” com botão de revogar.

Para tokens de API e integrações, decida se estão amarrados a uma sessão de usuário (então o MFA deve controlar criação e mudanças de escopo) ou chaves de longa duração (então confie em escopos restritos, expirações e rotação em vez de forçar MFA a cada chamada).

Erros comuns que causam bloqueios e fogo no suporte

A maioria dos problemas de MFA não é matemática. Acontecem porque os caminhos “e se eu não conseguir entrar?” nunca foram finalizados.

Erro 1: Habilitar MFA antes da recuperação ser real

Times colocam o prompt de MFA no ar mas deixam códigos de recuperação não testados, difíceis de achar ou quebrados no mobile. O resultado é bloqueios instantâneos.

Antes de ligar qualquer interruptor, teste a recuperação de ponta a ponta com uma conta nova e um cenário “telefone perdido”: gere códigos, use um, regenere, e confirme que os antigos deixam de funcionar.

Erro 2: Tratar segredos como dados normais

Sementes TOTP e códigos de recuperação não são como um nome de usuário. Se estiverem em texto claro, copiados em logs ou exibidos novamente depois, um vazamento vira takeover.

Armazene apenas o necessário, proteja como uma senha e nunca mostre códigos de recuperação de novo após a configuração. Se usuários precisarem, que regenere.

Erro 3: “O suporte pode simplesmente contornar”

Um bypass manual do MFA parece útil até virar o caminho mais fácil para entrar em contas. Se precisar de um bypass, torne‑o limitado no tempo, exija passos de verificação e deixe um rastro de auditoria para revisar.

Erro 4: Tratamento fraco de TOTP

Falhas de TOTP vêm de drift de relógio, reuso e ausência de rate limits. Aceitar o mesmo código duas vezes ou permitir uma janela de tempo muito larga facilita brute force e replay.

Mantenha simples: permita uma pequena janela de tempo, mas bloqueie reuso dentro dessa janela, limite tentativas, use bloqueios temporários (não tijolos permanentes) e mostre erros claros para “errado” vs “expirado”.

Erro 5: Assumir que passkeys se comportam igual em todo lugar

Passkeys podem falhar de formas surpreendentes: mudança de dispositivo, diferenças de suporte entre navegadores ou usuários sem credencial sincronizada. Se seu app exigir passkeys sem backup, você vai trancar pessoas reais.

Mantenha um fallback claro (TOTP ou códigos de recuperação) e teste em pelo menos um iOS, um Android e um navegador desktop.

Checklist rápido antes de lançar o MFA

Um hábito chato salva depois: garanta que você veja o que acontece e possa desfazer rápido.

Checagens pré‑lançamento (para recuperar rápido)

Confirme que pode reverter a mudança de MFA (feature flag, switch de config ou deploy rápido). Ative logs de auditoria para eventos chave como enroll, verify, fail, lockout, uso de código de recuperação e disable. Faça backup da tabela de usuários (e de quaisquer tabelas relacionadas ao MFA) e pratique restaurar para uma cópia segura. Verifique que o tracking de erros captura falhas de auth com detalhe suficiente para debug sem logar segredos ou códigos. Teste revogação de sessão para que, quando configurações de MFA mudarem, sessões antigas sejam rechecadas ou desconectadas.

Depois, teste jornadas de usuário de ponta a ponta. Não pare em “código aceito”. Siga até a primeira tela após login.

Jornadas de usuário e checagens de segurança

Atue alguns cenários:

• Um usuário novo se inscreve no MFA e depois entra em um segundo dispositivo.
• Um usuário existente habilita MFA, sai e volta a entrar com dispositivo lembrado ligado e desligado.
• Telefone perdido: um código de recuperação funciona uma vez, depois o usuário regenera códigos e reinscreve.
• Mudança de e‑mail e fluxo de redefinição exigem MFA (ou um step‑up seguro) antes de efetivar.
• Resistência a abuso: rate limits em tentativas de senha e de códigos MFA, mais bloqueios temporários que não brickem a conta.

Prepare‑se para o primeiro ticket de suporte com um script curto: o que perguntar, o que verificar nos logs e quando escalar.

Exemplo de rollout para um app protótipo simples

Imagine um protótipo SaaS: usuários entram com e‑mail e senha, e há uma área admin para faturamento, gerenciamento de usuários e ferramentas de suporte. Você quer mais segurança, mas não pode arriscar trancar pessoas.

Comece protegendo as contas de maior risco (admins) e expanda para todos quando o fluxo estiver estável e sem surpresas.

Fase 1: TOTP opcional para admins

Habilite TOTP apenas para contas admin, e mantenha opcional no início. Coloque o prompt nas configurações admin, não no meio de um login apressado.

Uma configuração simples: o admin se inscreve no TOTP, o app mostra códigos de recuperação uma vez, o admin confirma um código TOTP e o próximo login pede senha + TOTP. Se o TOTP falhar, um código de recuperação permite entrar.

Garanta sempre um caminho de volta. Se um admin não consegue completar o MFA, ainda deve conseguir entrar com senha e contatar suporte (temporariamente) em vez de ficar bloqueado.

Fase 2: Passkeys para usuários regulares, TOTP como backup

Quando os admins estiverem estáveis, ofereça passkeys para usuários regulares como opção mais fácil. Mantenha o TOTP disponível como backup para quem não pode usar passkeys (dispositivos antigos, computadores compartilhados).

Liberte devagar: ofereça “Adicionar um passkey” após o login e depois torne o MFA padrão para novos cadastros.

Uma falha real, tratada com calma

Um usuário perde o telefone e não tem acesso ao TOTP. Ele entra com e‑mail e senha, escolhe “Usar um código de recuperação” e entra. Logo em seguida, você pede para reinscrever um novo passkey (ou novo TOTP) e regenerar códigos de recuperação. Remova o método antigo só depois que o novo estiver confirmado.

Próximos passos e quando pedir ajuda

Se quer MFA sem bloquear logins, comece com um plano curto que sua equipe possa compartilhar: quem recebe MFA primeiro, como alguém entra se o MFA falhar e o que é sucesso (menos logins arriscados, não mais tickets de suporte).

Faça um rollout interno pequeno usando contas reais, dispositivos reais e condições reais (novo telefone, telefone perdido, drift de tempo, modo privacidade do navegador). Mantenha o piloto pequeno para que você possa observar cada falha e consertar rápido.

Decida algumas coisas por escrito antes de apertar qualquer botão: escopo da fase 1, opções de fallback, o que logar e revisar, quem pode resetar ou sobrescrever e qual prova é necessária, e quando a aplicação começa a ser obrigatória (mais como os usuários serão avisados). Após o rollout, observe o atrito cedo. Picos em erros “código inválido” geralmente apontam para drift de tempo, copy confusa ou usuários inscrevendo o dispositivo errado. Picos no uso de códigos de recuperação podem significar que a inscrição em passkey ou TOTP não está se mantendo.

Peça ajuda quando vir bloqueios repetidos, propriedade de workflows de reset pouco clara ou sinais de que seu código de auth é frágil (segredos hard‑coded, sessões inconsistentes ou bypasses estranhos). Se você herdou um protótipo gerado por IA, FixMyMess (fixmymess.ai) pode rodar uma auditoria gratuita de código para identificar riscos de bloqueio e os pontos específicos onde seu fluxo atual pode contornar ou quebrar o MFA antes de você forçar para todos.