Autenticação em múltiplos fatores
TOTP, chaves de acesso e SMS, e o que cada fator protege de fato.
As decisões de MFA são cinco: quais fatores oferecer, quando exigir o segundo fator, como guardar os segredos, como recuperar o acesso e se o MFA é obrigatório.
Quais fatores oferecer
| Chave de acesso | TOTP | Push no aplicativo | SMS | ||
|---|---|---|---|---|---|
| Resiste a phishing | Sim | Não | Não, e sofre com "aprovações por cansaço" | Não | Não |
| Resiste a SIM swap | Sim | Sim | Sim | Não | Depende do e-mail |
| Funciona sem rede no celular | Sim | Sim | Não | Precisa de sinal | Precisa de internet |
| Atrito para o usuário | Baixo, depois de configurado | Médio: abrir o aplicativo e digitar | Baixo | Baixo | Médio |
| Custo para quem oferece | Biblioteca WebAuthn | Biblioteca TOTP | Aplicativo próprio ou serviço | Por mensagem enviada | Quase nenhum |
| Pode substituir a senha | Sim | Não | Não | Não | Não |
A ordem de preferência para a maioria dos sistemas: chave de acesso, depois TOTP, e SMS como último recurso para quem não tem outra opção. O push em aplicativo próprio faz sentido para bancos e serviços que já têm aplicativo, com um cuidado: mostrar um número na tela do login que o usuário precisa escolher no celular, para ele não aprovar por reflexo um pedido que não fez.
Chave de acesso como senha, ou como segundo fator
| Uso | Como funciona | Quando |
|---|---|---|
| No lugar da senha | Login só com a chave; o dispositivo pede digital ou PIN | Sistemas novos, ou como opção principal para quem já tem a chave |
| Como segundo fator | Senha e depois a chave | Migração gradual, a partir de um sistema com senha |
A primeira forma elimina a senha, e com ela os vazamentos e a reutilização. A segunda é a porta de entrada mais simples num sistema que já existe.
Quando exigir o segundo fator
| Momento | Recomendação |
|---|---|
| Login num dispositivo novo | Sempre |
| Login num dispositivo conhecido | Pode pular por alguns dias, com um cookie de "dispositivo confiável" |
| Ações sensíveis | Pedir de novo: trocar e-mail, senha ou fatores, ver chaves de API, transferir dinheiro |
| Login com sinais de risco | Pedir mesmo em dispositivo conhecido: país novo, muitos erros de senha recentes |
Pedir o segundo fator de novo antes das ações sensíveis (step-up) fecha a brecha da sessão roubada: o cookie capturado entra na conta, mas não consegue trocar o e-mail nem desativar o MFA.
Como guardar os segredos
| Dado | Como guardar | Por quê |
|---|---|---|
| Segredo TOTP | Criptografado com uma chave fora do banco | O servidor precisa do segredo original para calcular os códigos; hash não serve |
| Último passo TOTP usado | Um número por usuário | Recusar o mesmo código duas vezes |
| Chave pública WebAuthn | Como está | É pública por definição |
| Contador de assinaturas WebAuthn | Um número por chave | Alguns autenticadores o usam para detectar cópias da chave |
| Códigos de recuperação | Hash, um por linha, marcado ao usar | Cada código só pode ser usado uma vez |
Os códigos de recuperação são aleatórios e longos, então um hash rápido como o SHA-256 basta. Diferente das senhas, eles não podem ser adivinhados com um dicionário.
Como recuperar o acesso
| Saída | Vantagem | Risco |
|---|---|---|
| Códigos de recuperação | O usuário resolve sozinho | Ele não guarda, ou guarda num lugar que também perde |
| Mais de um fator cadastrado | Perder um não trava a conta | Exige que o usuário cadastre o segundo |
| Suporte humano | Resolve qualquer caso | Vira alvo de engenharia social, se a conferência for fraca |
| Espera com aviso | Remove o fator depois de alguns dias, avisando todos os contatos | Lento; o usuário legítimo espera |
Uma combinação comum: códigos de recuperação no cadastro, incentivo a cadastrar um segundo fator, e o suporte como última saída, com espera e aviso. Remover o MFA por e-mail, sem mais nada, desfaz a proteção: quem invadiu o e-mail invade a conta.
Obrigatório ou opcional
| Público | Recomendação |
|---|---|
| Administradores, suporte, quem tem acesso a dados de outros | Obrigatório, e de preferência resistente a phishing |
| Contas com dinheiro ou dados sensíveis | Obrigatório, ou fortemente incentivado |
| Usuários comuns | Opcional, oferecido no cadastro e lembrado periodicamente |
O MFA opcional costuma ter adesão baixa. Chaves de acesso ajudam porque substituem a senha com menos atrito, e o usuário as adota pela conveniência, e não pela segurança.
Resumo da decisão
- Chaves de acesso como opção principal, TOTP como alternativa, SMS só como último recurso.
- Limite de tentativas por conta na conferência do código.
- Uso único de cada código TOTP, guardando o último passo aceito.
- Segundo fator de novo antes de ações sensíveis.
- Segredos TOTP criptografados, códigos de recuperação com hash.
- Recuperação com códigos e um segundo fator cadastrado, e um suporte tão rigoroso quanto o login.
- Obrigatório para administradores e contas sensíveis.
O próximo nível mostra o TOTP nas cinco linguagens, conferido com os vetores do RFC 6238, e o fluxo de chave de acesso testado no Chrome.
Prompts para aprofundar
Ao abrir no ChatGPT ou no Claude, o prompt é enviado ao serviço escolhido pela URL e também fica copiado na sua área de transferência.
Escolher os fatores do meu sistema
Quero decidir quais fatores de autenticação oferecer no meu sistema. Pergunte quem são os usuários, o que uma conta invadida expõe, se já existe um aplicativo próprio e qual é a infraestrutura de autenticação hoje. Compare para o meu caso chaves de acesso, TOTP, push no aplicativo, SMS e e-mail quanto a phishing, SIM swap, atrito, custo e recuperação. Recomende quais oferecer, em que ordem, e se o MFA deve ser obrigatório para algum grupo de usuários.
Quando pedir o segundo fator
Quero definir em que momentos o meu sistema pede o segundo fator. Pergunte quais ações existem no sistema, quais são sensíveis e como as sessões funcionam hoje. Proponha uma política para: 1. Login em dispositivo novo e em dispositivo conhecido. 2. Dispositivos confiáveis, e por quanto tempo. 3. Ações sensíveis que pedem o segundo fator de novo. 4. Sinais de risco que exigem o segundo fator mesmo em dispositivo conhecido. 5. O que acontece com as outras sessões quando um fator muda.
Migrar para chaves de acesso
Meu sistema usa senha, e talvez TOTP, e quero oferecer chaves de acesso. Pergunte qual linguagem e framework eu uso, se uso um provedor de identidade e quais navegadores e dispositivos os usuários têm. Monte um plano de migração: 1. Chave de acesso como segundo fator ou no lugar da senha. 2. Como convidar os usuários a criar a chave. 3. Como lidar com vários dispositivos e a sincronização das chaves. 4. A recuperação de quem perde todos os dispositivos. 5. Como medir a adoção.