Como Adicionar Autenticação de Dois Fatores à Sua App

Para adicionar autenticação de dois fatores (2FA) à sua app, deixe os utilizadores ligar uma aplicação de autenticação lendo um código QR, peça o código de seis dígitos que ela mostra depois da palavra-passe, e só crie uma sessão completa no servidor quando esse código estiver correto. Dê a cada utilizador códigos de recuperação de uso único quando ativar a funcionalidade, limite o número de tentativas de adivinhação, e exija a palavra-passe mais um código atual antes de o 2FA poder ser desligado. Se usar um fornecedor de autenticação alojado, ative a sua opção integrada de multifator em vez de construir a sua própria.

Este guia percorre as escolhas, o fluxo exato, prompts que pode dar a um criador com IA e os erros que fazem o 2FA parecer presente sem fazer nada. Se o conceito for novo, comece por o que é a autenticação de dois fatores.

Antes de começar: precisa de um login a funcionar

O 2FA assenta sobre um início de sessão já existente. Precisa de um destes primeiro:

• Um login próprio, com utilizadores e palavras-passe com hash guardados na base de dados da sua app.
• Um fornecedor de autenticação alojado que gere os utilizadores por si.

Se ainda não tiver nenhum dos dois, comece por como adicionar login à sua app. O resto deste guia assume que um passo de palavra-passe já funciona.

Escolha o seu segundo fator

TOTP significa palavra-passe temporária de uso único baseada no tempo, a norma (RFC 6238) que as aplicações de autenticação usam. O seu servidor e o telemóvel do utilizador partilham um segredo; cada um gera o mesmo código curto a partir desse segredo e da hora atual, normalmente mudando a cada 30 segundos. Não é preciso ligação à rede nem um fornecedor de SMS.

Chaves de acesso substituem ou complementam a palavra-passe com uma chave criptográfica guardada no dispositivo do utilizador. São mais fortes, mas dão mais trabalho para construir por si, por isso muitas apps começam com o TOTP e acrescentam chaves de acesso mais tarde, ou obtêm-nas de um fornecedor de autenticação.

Construir ou ativar?

Verifique a documentação atual do seu fornecedor para saber que fatores suporta e em que planos. Em qualquer dos casos, nunca escreva você a matemática de geração de códigos; use uma biblioteca amplamente utilizada.

Decida primeiro a política

Responda a estas perguntas antes de escrever os prompts, porque mudam o desenho:

1. Quem tem de o usar? Opcional para todos, obrigatório para administradores e funcionários, ou obrigatório para todos. Exigi-lo a quem tem poderes de administração é comum. Veja controlo de acesso baseado em funções.
2. Com que frequência os utilizadores voltam a introduzir um código? Em cada início de sessão, ou uma vez por dispositivo durante 30 dias («lembrar este dispositivo»).
3. Que ações exigem nova verificação? Alterar o email, os dados de pagamento ou desligar o 2FA são bons candidatos. Isto chama-se autenticação de reforço (step-up).
4. Qual é o processo para um telemóvel perdido? Códigos de recuperação, mais uma alternativa manual que esteja disposto a executar.

Passo a passo: 2FA com TOTP no seu próprio login

1. Guarde os campos certos

Cada utilizador precisa de: se o 2FA está ativo, o segredo TOTP (cifrado em repouso, não em texto simples), a data em que foi ativado, e uma lista de códigos de recuperação guardados com hash, como as palavras-passe. Acrescente um sítio onde contar as tentativas falhadas.

2. Registo

1. O utilizador abre as Definições e clica em Ativar a autenticação de dois fatores.
2. O servidor gera um segredo novo e devolve-o como código QR, mais a versão em texto para quem não consegue ler o código.
3. O utilizador lê-o numa aplicação de autenticação e escreve o código atual.
4. O servidor verifica o código. Só se estiver correto é que guarda o segredo e marca o 2FA como ativo.
5. A app mostra 8 a 10 códigos de recuperação uma única vez e pede ao utilizador que os guarde.

O passo 4 é importante: ativar o 2FA antes de confirmar um código bloqueia quem fez mal a leitura.

3. Início de sessão com um segundo passo

1. O utilizador envia o email e a palavra-passe. O servidor verifica-os.
2. Se o 2FA estiver ativo, o servidor não cria uma sessão completa. Cria, em vez disso, um estado de «segundo fator pendente» de curta duração.
3. A app mostra o ecrã do código. O servidor verifica o código, permitindo uma pequena margem para a diferença de relógio.
4. Só agora o servidor emite a sessão real.

Cada rota protegida e cada endpoint da API tem de rejeitar o estado pendente. Um ecrã de 2FA que apenas esconde páginas no navegador pode ser contornado chamando a API diretamente.

4. Limites e alertas

Um código de seis dígitos tem um milhão de combinações, o que é adivinhável sem limites. Limite as tentativas, bloqueie o segundo passo durante um período após falhas repetidas, e envie um email ao utilizador quando isso acontecer. Veja limitação de pedidos (rate limiting) e enviar emails a partir da sua app.

5. Recuperação e desativação

• Um código de recuperação funciona uma vez e depois é apagado.
• Desativar o 2FA exige a palavra-passe e um código atual ou um código de recuperação.
• Gerar novos códigos de recuperação invalida o conjunto anterior.
• Envie um email ao utilizador sempre que o 2FA for ativado ou desativado.

Prompts para dar ao seu criador com IA

Comece pelo fluxo principal:

Adicione autenticação de dois fatores opcional com aplicações de autenticação (TOTP) ao nosso login atual com email e palavra-passe. Use uma biblioteca TOTP conhecida, não escreva o algoritmo você mesmo. Nas Definições, mostre um código QR e o segredo em texto, e só ative o 2FA depois de o utilizador introduzir um código válido. Guarde o segredo cifrado e nunca o volte a mostrar depois da configuração. Mostre 10 códigos de recuperação de uso único uma vez e guarde-os com hash.

Depois, a aplicação das regras, que é onde o código gerado mais costuma ficar aquém:

Aplique o 2FA no servidor. Depois de uma palavra-passe correta, os utilizadores com 2FA ativo recebem um estado pendente de curta duração, e não uma sessão completa. Cada página e rota de API protegida tem de rejeitar o estado pendente. Limite as tentativas de código a 5; depois bloqueie o segundo passo durante 15 minutos e envie um email ao utilizador.

Depois, a política:

Exija 2FA para as contas de administrador: um administrador sem 2FA é enviado para a configuração e não pode aceder ao painel até a concluir. Exija a palavra-passe e um código atual para desligar o 2FA ou alterar o email da conta. Envie um email ao utilizador quando o 2FA for ativado ou desativado.

Por fim, peça ao agente que explique o que construiu:

Liste cada rota que verifica se um segundo fator foi concluído, onde estão guardados o segredo TOTP e os códigos de recuperação, e como estão protegidos.

Erros comuns

• Sessão emitida após a palavra-passe. É o erro mais grave. Se a sessão completa existir antes de o código ser verificado, o 2FA é apenas decoração. Teste chamando uma API protegida apenas após o passo da palavra-passe.
• Sem limite de tentativas. Adivinhações ilimitadas tornam o código passível de força bruta.
• Segredos ou códigos de recuperação em texto simples. Uma fuga da base de dados entrega o segundo fator de todos.
• Ativar antes de verificar. Os utilizadores que leram mal o código ficam bloqueados no início de sessão seguinte.
• Sem caminho de recuperação. Cada telemóvel perdido torna-se um pedido de apoio ou um cliente perdido.
• Desativação fácil. Se uma sessão roubada puder desligar o 2FA sem código, a proteção desaparece.
• Códigos nos registos. Garanta que códigos e segredos nunca aparecem nos registos do servidor ou em mensagens de erro.
• Verificar apenas na página de início de sessão. A recuperação de palavra-passe, o início de sessão por link mágico e qualquer login social têm de respeitar o 2FA também, ou tornam-se uma forma de o contornar.

Lista de verificação de testes

• O registo só é concluído depois de um código válido
• Início de sessão com palavra-passe correta mas sem código não dá acesso a nenhuma página ou API protegida
• Um código errado é recusado; tentativas erradas repetidas acionam o bloqueio e um email
• Um código de há alguns minutos é recusado
• Cada código de recuperação funciona exatamente uma vez
• Desligar o 2FA exige a palavra-passe e um código atual
• A recuperação de palavra-passe não contorna o 2FA
• Administradores sem 2FA não conseguem aceder às páginas de administração (se for obrigatório)
• Segredos e códigos de recuperação cifrados ou com hash na base de dados
• Nenhum código ou segredo aparece nos registos

Execute também a lista de verificação de segurança para apps criadas com IA completa antes do lançamento.

Adicionar 2FA na Mythex

A Mythex não inclui um sistema de login integrado para os utilizadores finais da sua app, por isso o 2FA faz parte da abordagem de autenticação que escolher: o seu próprio login com email e palavra-passe usando a base de dados do projeto, ou um fornecedor alojado com suporte multifator. Descreve o que quer no chat com prompts como os acima, e as chaves do fornecedor vão para os segredos do projeto (através de /secrets, das definições do projeto ou do cartão de segredos que o agente mostra) e não para a caixa de mensagens. A receita da documentação Adicionar login à sua app tem um prompt inicial, e Segurança para apps que cria cobre os hábitos em torno de chaves e permissões. Depois de o agente terminar, teste todos os itens da lista de verificação em Preview antes de publicar.

Perguntas