---
term: 'Autenticação Multifator (MFA)'
seoTitle: 'Autenticação Multifator (MFA): Métodos Comparados, TOTP, Passkeys'
headline: 'O que é Autenticação Multifator (MFA)?'
slug: autenticacao-multifator-mfa
category: auth-security
shortDefinition: '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ê é.'
relatedTerms:
  - passwordless-authentication
  - oauth-2-social-login
  - identity-access-management-iam
  - json-web-token-jwt
contrastsWith:
  - passwordless-authentication
aboutTerms:
  - 'TOTP'
  - 'MFA Resistente a Phishing'
  - 'Passkeys'
  - 'Fadiga de MFA'
faq:
  - question: 'O que é MFA em termos simples?'
    answer: 'Um login que exige duas ou mais provas de tipos diferentes — digamos, uma senha mais um código do seu celular — para que uma senha roubada, sozinha, não abra nada. As provas precisam vir de categorias distintas: senha mais pergunta de segurança continua sendo um fator só, duas vezes.'
  - question: 'Qual a diferença entre MFA e 2FA?'
    answer: 'Escopo. 2FA significa exatamente dois fatores; MFA significa dois ou mais. Todo 2FA é MFA e, na prática, a maioria das implantações de MFA é 2FA. O número importa menos que a qualidade — dois fatores resistentes a phishing valem mais que três fatores phishável.'
  - question: 'Quais são os três fatores de autenticação?'
    answer: 'Algo que você sabe (senha, PIN), algo que você tem (celular, chave de hardware), algo que você é (impressão digital, rosto). Localização e comportamento aparecem como sinais suplementares, mas alimentam checagens adaptativas, baseadas em risco, em vez de valerem como fatores por si sós.'
  - question: 'Verificação em duas etapas por SMS é segura?'
    answer: 'Melhor que senha sozinha, mas é o método comum mais fraco: SIM swap, interceptação nos protocolos de telefonia e phishing corriqueiro o derrotam. Órgãos de padronização o restringem há anos, e a orientação governamental atual é direta — não use SMS como segundo fator onde houver qualquer opção mais forte.'
  - question: 'Como funciona um app autenticador TOTP?'
    answer: 'No cadastro, o QR code entrega ao app um segredo compartilhado. Dali em diante, app e servidor computam de forma independente um código a partir desse segredo e da janela de 30 segundos atual; códigos iguais provam a posse. Tudo offline — sem rede, sem conta com o fabricante do app, só relógios sincronizados e matemática.'
  - question: 'Passkeys substituem a MFA?'
    answer: 'Para a maioria das contas, na prática sim: uma passkey é multifator em um único gesto — posse do dispositivo mais a biometria ou o PIN que o desbloqueia — e ainda resistente a phishing, já que a assinatura só funciona no site genuíno. Contextos de alta criticidade ainda podem exigir um fator separado por cima.'
  - question: 'O que é MFA resistente a phishing?'
    answer: 'MFA que não pode ser retransmitida por um site falso. Códigos e aprovações por push podem ser repassados em tempo real; métodos de chave pública — passkeys e chaves de segurança de hardware sob WebAuthn — vinculam a resposta criptograficamente ao domínio real, então um site imitador recebe uma assinatura que não vale nada em nenhum outro lugar.'
  - question: 'O que é um ataque de fadiga de MFA?'
    answer: 'Bombardeio de push: um atacante com a senha roubada dispara pedidos de aprovação até a vítima exausta tocar em sim — o método por trás de violações famosas. Mitigações, em ordem: number matching nos avisos, limites de tentativas e, por fim, migrar para métodos em que não há nada a aprovar.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'NIST SP 800-63B — Digital Identity Guidelines: Authentication'
    url: 'https://pages.nist.gov/800-63-3/sp800-63b.html'
  - name: 'RFC 6238 — TOTP: Time-Based One-Time Password Algorithm'
    url: 'https://datatracker.ietf.org/doc/html/rfc6238'
  - name: 'CISA — Implementing Phishing-Resistant MFA'
    url: 'https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf'
  - name: 'W3C Web Authentication (WebAuthn)'
    url: 'https://www.w3.org/TR/webauthn-2/'
  - name: 'Multi-factor authentication — Wikipedia'
    url: 'https://en.wikipedia.org/wiki/Multi-factor_authentication'
cta:
  title: 'Autenticação step-up sem precisar construí-la'
  text: 'O adaptador de MFA do Back4app adiciona TOTP ao seu fluxo de login com um bloco de configuração — cadastro, janelas de verificação e códigos de recuperação por conta da plataforma, sobre sessões que ela revoga na hora.'
  linkText: 'Comece grátis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-08-21'
translationKey: multi-factor-authentication-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

| Pergunta | Resposta |
| --- | --- |
| Os fatores | Sabe (senha) · tem (dispositivo, chave) · é (biometria) — de categorias *diferentes* |
| MFA vs. 2FA | 2FA = exatamente dois; MFA = dois ou mais; qualidade vale mais que quantidade |
| O ranking | SMS < TOTP < push < push + number matching < **passkeys / chaves de segurança** |
| A linha divisória | Resistência a phishing: códigos podem ser retransmitidos; criptografia presa à origem, não |
| O elo fraco | Recuperação — fluxos de reset precisam ser tão fortes quanto o login que substituem |

## Como o TOTP realmente funciona

O app autenticador, desmistificado — nenhuma página de ranking explica a maquinaria ([RFC 6238](https://datatracker.ietf.org/doc/html/rfc6238)):

```text
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:**

```javascript
// 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
// 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();
```

**Swift:**

```swift
// 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]])
```

**Kotlin:**

```kotlin
// 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

| | 2FA | MFA |
| --- | --- | --- |
| Fatores | Exatamente dois | Dois ou mais |
| Relação | Um subconjunto da MFA | O termo guarda-chuva |
| Na prática | O que a maioria das implantações é | Como a maioria das implantações é chamada |

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](https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf) publica e os explicadores de fornecedor evitam — quais ataques derrotam quais métodos:

| Método | Phishing / proxy em tempo real | SIM swap | Bombardeio de push | Offline? | Veredito |
| --- | --- | --- | --- | --- | --- |
| Códigos por SMS / voz | Derrotado | **Derrotado** | n/a | Não | Último recurso — [restrito pelo NIST](https://pages.nist.gov/800-63-3/sp800-63b.html) |
| Códigos por e-mail | Derrotado | Seguro | n/a | Não | Herda a segurança da sua caixa de entrada |
| App TOTP | Derrotado | Seguro | n/a | **Sim** | A linha de base sólida |
| Aprovação por push | Derrotado | Seguro | **Derrotado** | Não | Conveniente, bombardeável |
| Push + number matching | Derrotado | Seguro | Resistente | Não | Conveniência remendada |
| **Passkeys / chaves de segurança** | **Resistente** | Seguro | n/a | Sim | O padrão-ouro ([WebAuthn](https://www.w3.org/TR/webauthn-2/)) |

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

```mermaid
flowchart LR
  accTitle: Proxy de phishing adversary-in-the-middle retransmitindo a MFA
  accDescr: A vítima digita credenciais e um código de uso único em um site falso, que os retransmite em tempo real ao site genuíno, recebe uma sessão válida e entrega o cookie de sessão ao atacante. Passkeys derrotam o ataque porque sua assinatura é vinculada ao domínio genuíno e falha no falso.
  V["Vítima"] -->|"senha + código OTP"| F["Página de login falsa<br/>(kit de proxy)"]
  F -->|"retransmite em tempo real"| R["Site real"]
  R -->|"cookie de sessão válido"| F
  F -->|"sessão entregue"| A["Atacante logado"]
  P["Tentativa de passkey na página falsa"] -.->|"assinatura presa ao domínio real<br/>→ inútil para o proxy"| X["Falha"]
```

**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](/glossary/pt/json-web-token-jwt/) 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](/glossary/pt/oauth-2-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

| Situação | Ofereça |
| --- | --- |
| Base geral de usuários, dispositivos variados | TOTP como linha de base + passkeys como caminho promovido |
| Contas de alto valor ou de admin | Só resistente a phishing — passkeys / chaves de segurança |
| Usuários sem smartphone | Chaves de hardware ou códigos de backup impressos, não SMS por padrão |
| População legada, nada mais viável | SMS — de olhos abertos, como piso e não como norma |
| Ações sensíveis dentro do app | Reautenticação step-up, qualquer que seja o fator do login |
| Design da recuperação | Mínimo de dois métodos cadastrados + códigos offline |

## 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.