¿Qué es la Autenticación Multifactor (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

Cómo funciona el TOTP en realidad

La app de autenticación, desmitificada — ninguna página de rankings explica la maquinaria (RFC 6238):

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

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 y los explicadores de proveedores evitan — qué ataques derrotan a qué métodos:

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

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; 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 — 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

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.