---
term: 'Autenticación Multifactor (MFA)'
seoTitle: 'Autenticación Multifactor (MFA): métodos comparados, TOTP, passkeys'
headline: '¿Qué es la Autenticación Multifactor (MFA)?'
slug: autenticacion-multifactor-mfa
category: auth-security
shortDefinition: 'La autenticación multifactor es un control de login que exige dos o más pruebas de tipos distintos — algo que sabes, que tienes o que eres.'
relatedTerms:
  - passwordless-authentication
  - oauth-2-social-login
  - identity-access-management-iam
  - json-web-token-jwt
contrastsWith:
  - passwordless-authentication
aboutTerms:
  - 'TOTP'
  - 'MFA Resistente al Phishing'
  - 'Passkeys'
  - 'Fatiga de MFA'
faq:
  - question: '¿Qué es la MFA en términos simples?'
    answer: 'Un inicio de sesión que exige dos o más pruebas de tipos distintos — digamos, una contraseña más un código de tu teléfono — para que una contraseña robada por sí sola no abra nada. Las pruebas deben venir de categorías diferentes: una contraseña más una pregunta de seguridad sigue siendo un solo factor, dos veces.'
  - question: '¿Cuál es la diferencia entre MFA y 2FA?'
    answer: 'El alcance. 2FA significa exactamente dos factores; MFA significa dos o más. Toda 2FA es MFA, y en la práctica la mayoría de los despliegues de MFA son 2FA. El número importa menos que la calidad — dos factores resistentes al phishing le ganan a tres phishables.'
  - question: '¿Cuáles son los tres factores de autenticación?'
    answer: 'Algo que sabes (contraseña, PIN), algo que tienes (teléfono, llave de hardware), algo que eres (huella, rostro). La ubicación y el comportamiento aparecen como señales complementarias, pero alimentan verificaciones adaptativas basadas en riesgo en lugar de valer como factores por sí solos.'
  - question: '¿La verificación por SMS es segura?'
    answer: 'Mejor que una contraseña sola, pero el método común más débil: el SIM swapping, la interceptación de protocolos de telecomunicaciones y el phishing ordinario lo derrotan. Los organismos de estándares lo restringen desde hace años, y la guía gubernamental actual es directa — no uses SMS como segundo factor donde haya algo más fuerte disponible.'
  - question: '¿Cómo funciona una app de autenticación TOTP?'
    answer: 'En el enrolamiento, el código QR le entrega a la app un secreto compartido. Desde entonces, app y servidor computan de forma independiente un código a partir de ese secreto y la ventana de tiempo de 30 segundos vigente; los códigos coincidentes prueban la posesión. Totalmente offline — sin red, sin cuenta con el fabricante de la app, solo relojes sincronizados y matemática.'
  - question: '¿Las passkeys reemplazan a la MFA?'
    answer: 'Para la mayoría de las cuentas, en efecto sí: una passkey es multifactor en un solo gesto — la posesión del dispositivo más la biometría o el PIN que lo desbloquea — y además resistente al phishing, porque la firma solo funciona en el sitio genuino. Los contextos de alta garantía todavía pueden sumar un factor separado encima.'
  - question: '¿Qué es la MFA resistente al phishing?'
    answer: 'MFA que no puede retransmitirse a través de un sitio falso. Los códigos y las aprobaciones push pueden pasarse por un proxy en tiempo real; los métodos de clave pública — passkeys y llaves de seguridad de hardware bajo WebAuthn — vinculan la respuesta criptográficamente al dominio real, así que un sitio imitador recibe una firma que no vale nada en ningún otro lado.'
  - question: '¿Qué es un ataque de fatiga de MFA?'
    answer: 'Bombardeo de push: un atacante con una contraseña robada dispara avisos de aprobación hasta que la víctima agotada toca que sí — el método detrás de varias brechas famosas. Mitigaciones, en orden: number matching en los avisos, límites de tasa en los intentos y, en última instancia, migrar a métodos donde no hay nada que aprobar.'
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: 'Autenticación reforzada sin construirla'
  text: 'El adaptador de MFA de Back4app agrega TOTP a tu flujo de login con un bloque de configuración — enrolamiento, ventanas de verificación y códigos de recuperación a cargo de la plataforma, sobre sesiones que puede revocar al instante.'
  linkText: 'Empieza gratis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-08-31'
translationKey: multi-factor-authentication-mfa
---

**La autenticación multifactor es un control de login que exige dos o más pruebas de tipos distintos — algo que sabes, que tienes o que eres.** La palabra *distintos* carga el peso y se atropella con frecuencia: una contraseña más una pregunta de seguridad son dos pruebas de una misma categoría — conocimiento — y por lo tanto no son MFA en absoluto. El punto es combinatorio: una contraseña phisheada no sostiene tu teléfono; un teléfono robado no sabe tu PIN; el robo de cada factor deja al atacante a una categoría de distancia.

## Puntos clave

| Pregunta | Respuesta |
| --- | --- |
| Los factores | Sabes (contraseña) · tienes (dispositivo, llave) · eres (biometría) — de categorías *distintas* |
| MFA vs. 2FA | 2FA = exactamente dos; MFA = dos o más; la calidad vale más que la cantidad |
| El ranking | SMS < TOTP < push < push + number matching < **passkeys / llaves de seguridad** |
| La línea divisoria | Resistencia al phishing: los códigos pueden retransmitirse; la criptografía atada al origen, no |
| El eslabón débil | La recuperación — los flujos de reset deben ser tan fuertes como el login que reemplazan |

## Cómo funciona el TOTP en realidad

La app de autenticación, desmitificada — ninguna página de rankings explica la maquinaria ([RFC 6238](https://datatracker.ietf.org/doc/html/rfc6238)):

```text
Enrolamiento QR code = otpauth://totp/app:ada?secret=JBSWY3DP…
             → la app ahora comparte un SECRETO Base32 con el servidor

Cada 30 s    ambos lados computan, de forma independiente y offline:
             code = truncate( HMAC-SHA1( secret, floor(unix_time / 30) ) ) % 10⁶

Login        escribes los 6 dígitos de la app; el servidor computa los suyos,
             acepta ±1 ventana de tiempo por deriva de reloj → coinciden = posesión probada
```

Cableando eso al flujo de login de una 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 |
| --- | --- | --- |
| Factores | Exactamente dos | Dos o más |
| Relación | Un subconjunto de la MFA | El término paraguas |
| En la práctica | Lo que la mayoría de los despliegues es | Como se llama a la mayoría de los despliegues |

Una tabla zanja el asunto; la pregunta más filosa es *cuáles* factores — porque el techo de seguridad no lo fija cuántas pruebas apilas, sino si alguna de ellas puede phishearse.

## El ranking de métodos, con honestidad

La comparación que publica la [guía de CISA](https://www.cisa.gov/sites/default/files/publications/fact-sheet-implementing-phishing-resistant-mfa-508c.pdf) y los explicadores de proveedores evitan — qué ataques derrotan a qué métodos:

| Método | Phishing / proxy en tiempo real | SIM swap | Bombardeo de push | ¿Offline? | Veredicto |
| --- | --- | --- | --- | --- | --- |
| Códigos por SMS / voz | Derrotado | **Derrotado** | n/a | No | Último recurso — [restringido por el NIST](https://pages.nist.gov/800-63-3/sp800-63b.html) |
| Códigos por email | Derrotado | Seguro | n/a | No | Hereda la seguridad de tu bandeja de entrada |
| App TOTP | Derrotado | Seguro | n/a | **Sí** | La base sólida |
| Aprobación por push | Derrotado | Seguro | **Derrotado** | No | Conveniente, bombardeable |
| Push + number matching | Derrotado | Seguro | Resistente | No | Conveniencia parchada |
| **Passkeys / llaves de seguridad** | **Resistente** | Seguro | n/a | Sí | El estándar de oro ([WebAuthn](https://www.w3.org/TR/webauthn-2/)) |

El patrón de la columna de la izquierda es la historia moderna: *todo* código y toda aprobación pueden retransmitirse a través de un proxy de phishing; solo la criptografía atada al origen sobrevive al contacto con una página de login falsa.

## Los ataques, en lenguaje llano

```mermaid
flowchart LR
  accTitle: Proxy de phishing adversary-in-the-middle retransmitiendo la MFA
  accDescr: La víctima ingresa credenciales y un código de un solo uso en un sitio falso, que los retransmite en tiempo real al sitio genuino, recibe una sesión válida y le entrega la cookie de sesión al atacante. Las passkeys derrotan el ataque porque su firma está vinculada al dominio genuino y falla en el falso.
  V["Víctima"] -->|"contraseña + código OTP"| F["Página de login falsa<br/>(kit de proxy)"]
  F -->|"retransmite en tiempo real"| R["Sitio real"]
  R -->|"cookie de sesión válida"| F
  F -->|"sesión entregada"| A["Atacante con sesión"]
  P["Intento de passkey en la página falsa"] -.->|"firma atada al dominio real<br/>→ inútil para el proxy"| X["Falla"]
```

**Phishing adversary-in-the-middle:** kits de proxy open-source se sientan entre la víctima y el sitio real, retransmitiendo contraseña *y* código de un solo uso en vivo, y se quedan con la cookie de sesión resultante — la MFA "pasó", la cuenta se perdió. **Bombardeo de push:** con una contraseña robada, se disparan avisos de aprobación hasta que la fatiga gana un toque; el number matching (escribir los dígitos mostrados en pantalla) elimina el aprobar en piloto automático. **SIM swapping:** convencer a una operadora de migrar el número de la víctima y recibir sus códigos SMS — el ataque que puso al SMS al fondo de la tabla. El hilo común: todo esto derrota *factores que pueden contársele a alguien*; todo esto se rompe contra factores que solo hablan criptográficamente con el origen genuino.

## El problema de la recuperación

Todo despliegue de MFA crea una segunda puerta: ¿qué pasa cuando se pierde el teléfono? Los códigos de respaldo — de un solo uso, generados en el enrolamiento, guardados offline — son la respuesta estándar; los flujos de recuperación de cuenta son la peligrosa. Si una llamada al help desk o un reset por email puede quitar la MFA, el atacante llama al help desk — la técnica detrás de brechas de titulares — y tu control más fuerte queda anulado por tu proceso más débil. La regla: **la recuperación debe exigir una garantía igual o superior a la del login que reemplaza** — múltiples métodos enrolados, verificación step-up para los resets, y la eliminación de MFA tratada como un evento privilegiado, registrado y generador de alertas.

## ¿Qué tan efectiva es la MFA, en realidad?

Dos afirmaciones verdaderas, confundidas a menudo. Contra ataques *automatizados* — credential stuffing, password spraying — la MFA es casi total: las famosas cifras de noventa y nueve por ciento vienen de telemetría de inicios de sesión a gran escala midiendo exactamente eso, y un estudio revisado por pares encontró ~99% de reducción de compromisos en el mismo alcance. Contra el phishing *dirigido* con proxies en tiempo real, la MFA por código y por push es demostrablemente evadible — por eso los críticos estiman mucho más baja la efectividad contra todos los ataques, y por eso las agencias ahora empujan específicamente los métodos resistentes al phishing. La síntesis honesta: cualquier MFA termina la era en la que la contraseña bastaba; solo la MFA de clase passkey termina el phishing. Despliega *alguna* MFA en todas partes, y MFA resistente al phishing donde el riesgo justifique la fricción del enrolamiento.

## Casos de uso comunes

- **Proteger la emisión de cuentas** — la MFA custodia el momento en que se acuñan [sesiones y tokens](/glossary/es/json-web-token-jwt/); todo lo que sigue río abajo confía en esa compuerta.
- **Step-up para acciones sensibles** — vuelve a pedir prueba en el pago, la eliminación o la exportación de claves, no solo en el login.
- **Cuentas de admin y privilegiadas** — donde la MFA debe ser obligatoria y resistente al phishing, sin excepciones.
- **Regímenes de cumplimiento** — los marcos de pagos, salud y gobierno exigen MFA de forma cada vez más explícita.
- **Complementar el [login social](/glossary/es/oauth-2-login-social/)** — heredada del proveedor de identidad, o impuesta localmente para acciones de alto valor.

## ¿Qué método de MFA deberías ofrecer? Matriz de decisión

| Situación | Ofrece |
| --- | --- |
| Base general de usuarios, dispositivos variados | TOTP como base + passkeys como el camino promovido |
| Cuentas de alto valor o de admin | Solo resistente al phishing — passkeys / llaves de seguridad |
| Usuarios sin smartphone | Llaves de hardware o códigos de respaldo impresos, no SMS por defecto |
| Población legada, nada más viable | SMS — con los ojos abiertos, como piso y no como norma |
| Acciones sensibles dentro de la app | Re-autenticación step-up, sea cual sea el factor del login |
| Diseño de la recuperación | Mínimo dos métodos enrolados + códigos offline |

## Limitaciones y trade-offs

- **La fricción es real y medible.** Cada aviso cuesta conversión y tickets de soporte; los desafíos adaptativos, basados en riesgo, gastan la fricción donde vive el riesgo.
- **La MFA phishable compra menos de lo que parece.** Contra un ataque de proxy dirigido, códigos y pushes caen; trátalos como freno de automatización, no como blindaje anti-phishing.
- **El teléfono es un punto único de falla.** La pérdida del dispositivo sin plan de recuperación se convierte en bloqueo a escala — la UX de enrolamiento debe plantar métodos de respaldo desde el primer día.
- **Los flujos de recuperación invierten la matemática.** Un camino de reset débil limita en silencio todo tu esquema a su propia fuerza.
- **El enrolamiento es el precipicio de la adopción.** Los mandatos sin flujos de QR suaves y alternativas claras generan resistencia; el mejor esquema es el que los usuarios de verdad completan.

## La MFA en Back4app

Back4app es una plataforma open-source de Backend as a Service (BaaS) que combina base de datos gestionada, APIs REST y GraphQL generadas automáticamente, autenticación, almacenamiento de archivos y funciones serverless con Cloud Code. El TOTP llega como configuración, no como construcción: el adaptador de autenticación `mfa` de Back4app enciende los códigos basados en tiempo con un bloque de configuración — dígitos, período y algoritmo ajustables — y las pestañas de código muestran la historia completa del lado del cliente: el enrolamiento prueba la posesión emparejando el secreto compartido con un código válido, el servidor emite códigos de recuperación de un solo uso, y los logins siguientes combinan la contraseña con los seis dígitos del momento. Como las sesiones de la plataforma son revocables del lado del servidor, la higiene alrededor también se sostiene: un cambio de MFA puede terminar las otras sesiones de inmediato, y los triggers de Cloud Code son el lugar natural para registrar eventos de enrolamiento y encerrar la eliminación de MFA detrás de verificaciones step-up — la disciplina de recuperación que este artículo defiende, expresada en unas pocas funciones.