O que é Autenticação Multifator (MFA)?

Autenticação multifator é um controle de login que exige duas ou mais provas de tipos diferentes — algo que você sabe, que você tem ou que você é. A palavra diferentes carrega o peso e é amplamente atropelada: senha mais pergunta de segurança são duas provas de uma mesma categoria — conhecimento — e portanto não são MFA de forma alguma. O ponto é combinatório: uma senha phishada não segura o seu celular; um celular roubado não sabe o seu PIN; o roubo de cada fator deixa o atacante a uma categoria de distância.

Principais pontos

Como o TOTP realmente funciona

O app autenticador, desmistificado — nenhuma página de ranking explica a maquinaria (RFC 6238):

Cadastro     QR code = otpauth://totp/app:ada?secret=JBSWY3DP…
             → o app agora compartilha um SEGREDO Base32 com o servidor

A cada 30 s  os dois lados computam, de forma independente e offline:
             code = truncate( HMAC-SHA1( secret, floor(unix_time / 30) ) ) % 10⁶

Login        você digita os 6 dígitos do app; o servidor computa os dele,
             aceita ±1 janela de tempo para deriva de relógio → bateu = posse provada

Ligando isso ao fluxo de login de um app:

// JavaScript / Node.js — Back4app JS SDK
// TOTP step-up with the Parse Server mfa auth adapter
// Enroll: prove possession by sending one valid code with the secret
await currentUser.save({
  authData: { mfa: { secret: totpSecret, token: codeFromApp } },
});
// server returns single-use recovery codes — show once, store nowhere

// Log in afterwards: password + the current 6-digit code
const user = await Parse.User.logIn('ada', password, {
  authData: { mfa: { token: codeFromApp } },
});

// Flutter / Dart — Back4app Flutter SDK
// TOTP step-up with the Parse Server mfa auth adapter
// Enroll: prove possession by sending one valid code with the secret
currentUser.set('authData', {
  'mfa': {'secret': totpSecret, 'token': codeFromApp},
});
await currentUser.save();
// server returns single-use recovery codes — show once, store nowhere

// Log in afterwards: password + the current 6-digit code
final user = ParseUser('ada', password, null)
  ..set('authData', {'mfa': {'token': codeFromApp}});
await user.login();

// iOS / Swift — Back4app Swift SDK
// TOTP step-up with the Parse Server mfa auth adapter
// Enroll: prove possession by sending one valid code with the secret
let enrolled = try await currentUser.link("mfa",
    authData: ["secret": totpSecret, "token": codeFromApp])
// server returns single-use recovery codes — show once, store nowhere

// Log in afterwards: password + the current 6-digit code
let user = try await User.login("ada", password: password,
    authData: ["mfa": ["token": codeFromApp]])

// Android / Kotlin — Back4app Android SDK
// TOTP step-up with the Parse Server mfa auth adapter
// Enroll: prove possession by sending one valid code with the secret
val enroll = mapOf("secret" to totpSecret, "token" to codeFromApp)
ParseUser.getCurrentUser().linkWithInBackground("mfa", enroll)
// server returns single-use recovery codes — show once, store nowhere

// Log in afterwards: password + the current 6-digit code
val authData = mapOf("token" to codeFromApp)
ParseUser.logInWithInBackground("mfa", authData) // paired with the password check

MFA vs. 2FA

Uma tabela encerra o assunto; a pergunta mais afiada é quais fatores — porque o teto de segurança não é definido por quantas provas você empilha, e sim por alguma delas poder ser phishada.

O ranking dos métodos, com honestidade

A comparação que a orientação da CISA publica e os explicadores de fornecedor evitam — quais ataques derrotam quais métodos:

O padrão da coluna mais à esquerda é a história moderna: todo código e toda aprovação podem ser retransmitidos por um proxy de phishing; só a criptografia presa à origem sobrevive ao contato com uma página de login falsa.

Os ataques, em linguagem simples

Phishing adversary-in-the-middle: kits de proxy open-source se sentam entre a vítima e o site real, retransmitindo senha e código de uso único ao vivo, e ficam com o cookie de sessão resultante — a MFA “passou”, a conta se foi. Bombardeio de push: com uma senha roubada, dispare avisos de aprovação até a fadiga vencer um toque; o number matching (digitar os dígitos mostrados na tela) elimina o aprovar-no-piloto-automático. SIM swap: convença uma operadora a migrar o número da vítima e receba os SMS dela — o ataque que pôs o SMS no fundo da tabela. O fio comum: tudo isso derrota fatores que podem ser contados a alguém; tudo isso quebra contra fatores que só falam criptograficamente com a origem genuína.

O problema da recuperação

Toda implantação de MFA cria uma segunda porta: o que acontece quando o celular se perde? Códigos de backup — de uso único, gerados no cadastro, guardados offline — são a resposta padrão; fluxos de recuperação de conta são a perigosa. Se uma ligação ao help desk ou um reset por e-mail consegue remover a MFA, o atacante liga para o help desk — a técnica por trás de violações de manchete — e o seu controle mais forte é anulado pelo seu processo mais fraco. A regra: a recuperação deve exigir garantia igual ou superior à do login que substitui — múltiplos métodos cadastrados, verificação step-up para resets, e a remoção de MFA tratada como evento privilegiado, registrado e gerador de alerta.

Quão eficaz é a MFA, na prática?

Duas afirmações verdadeiras, sempre confundidas. Contra ataques automatizados — credential stuffing, password spraying — a MFA é quase total: os famosos números de noventa e nove por cento vêm de telemetria de login em larga escala medindo exatamente isso, e um estudo revisado por pares encontrou ~99% de redução de comprometimento no mesmo escopo. Contra phishing direcionado com proxies em tempo real, MFA por código e por push é comprovadamente contornável — por isso os críticos estimam a eficácia contra todos os ataques bem mais baixa, e por isso as agências agora empurram especificamente os métodos resistentes a phishing. A síntese honesta: qualquer MFA encerra a era em que a senha bastava; só a MFA de classe passkey encerra o phishing. Implante alguma MFA em tudo, e MFA resistente a phishing onde o risco justificar o atrito de cadastro.

Casos de uso comuns

• Proteger a emissão de contas — a MFA guarda o momento em que sessões e tokens são cunhados; tudo rio abaixo confia nessa cancela.
• Step-up para ações sensíveis — repita o desafio no pagamento, na exclusão ou na exportação de chaves, não só no login.
• Contas de admin e privilegiadas — onde a MFA deve ser obrigatória e resistente a phishing, sem exceções.
• Regimes de conformidade — frameworks de pagamento, saúde e governo exigem MFA cada vez mais explicitamente.
• Complementar o login social — herdada do provedor de identidade, ou imposta localmente para ações de alto valor.

Qual método de MFA você deveria oferecer? Matriz de decisão

Limitações e trade-offs

• O atrito é real e mensurável. Cada desafio custa conversão e tickets de suporte; prompts adaptativos, baseados em risco, gastam o atrito onde o risco mora.
• MFA phishável compra menos do que parece. Contra um ataque de proxy direcionado, códigos e pushes caem; trate-os como freio de automação, não como blindagem anti-phishing.
• O celular é um ponto único de falha. Perda do aparelho sem plano de recuperação vira bloqueio em escala — a UX de cadastro precisa plantar métodos de backup desde o primeiro dia.
• Fluxos de recuperação invertem a matemática. Um caminho de reset fraco limita silenciosamente o esquema inteiro à sua própria força.
• O cadastro é o penhasco da adoção. Obrigatoriedade sem fluxos de QR suaves e alternativas claras gera resistência; o melhor esquema é o que os usuários de fato completam.

MFA no Back4app

O Back4app é uma plataforma open-source de Backend as a Service (BaaS) que combina banco de dados gerenciado, APIs REST e GraphQL geradas automaticamente, autenticação, armazenamento de arquivos e funções serverless com Cloud Code. O TOTP chega como configuração, não como construção: o adaptador de autenticação mfa do Back4app liga códigos baseados em tempo com um bloco de configuração — dígitos, período e algoritmo ajustáveis — e as abas de código mostram a história inteira do lado do cliente: o cadastro prova a posse pareando o segredo compartilhado com um código válido, o servidor emite códigos de recuperação de uso único, e os logins seguintes combinam a senha com os seis dígitos do momento. Como as sessões da plataforma são revogáveis no servidor, a higiene em volta também se sustenta: uma mudança de MFA pode encerrar as outras sessões imediatamente, e os triggers de Cloud Code são o lugar natural para registrar eventos de cadastro e trancar a remoção de MFA atrás de checagens step-up — a disciplina de recuperação que este artigo defende, expressa em poucas funções.