Agregar MFA a una aplicación prototipo sin romper los inicios de sesión

Por qué MFA rompe los inicios de sesión de los prototipos con tanta frecuencia

Agregar MFA a una aplicación prototipo no es “una pantalla extra”. Cambia las reglas sobre quién puede entrar, qué pasa cuando algo sale mal y cuántos casos límite debe manejar tu flujo de inicio de sesión.

Las bases de código de los prototipos suelen tener autenticación frágil: sesiones y tokens mezclados, una fuente de verdad del usuario poco clara y atajos como saltarse la verificación por correo o reutilizar códigos de un solo uso. MFA expone rápido esos atajos. Un pequeño desajuste (desfase de tiempo en TOTP, registros de usuario duplicados o una carrera entre “verificar contraseña” y “crear sesión”) puede dejar fuera a usuarios reales.

“No romper los inicios de sesión” significa más que “la ruta feliz funciona”. La gente aún necesita iniciar sesión en dispositivos y navegadores antiguos, debe haber una forma segura de volver a entrar si pierden el segundo factor, y tu carga de soporte no puede dispararse con tickets de “estoy bloqueado”.

Antes de cambiar nada, mide tu línea base para poder decir si MFA ayudó o perjudicó. Rastrea unos cuantos números durante varios días: tasa de éxito de inicio de sesión, abandono por paso (contraseña ingresada, se mostró el prompt de código, código aceptado), eventos de bloqueo y completados de restablecimiento de contraseña, y el tiempo medio hasta iniciar sesión.

También decide a quién proteges primero. Forzar MFA a todos de inmediato maximiza la fricción y el soporte. Un punto de partida más seguro son las cuentas de alto riesgo como administradores, acceso a facturación y cualquiera que pueda cambiar ajustes de seguridad. Eso te da datos del mundo real sin convertir todo tu inicio de sesión en un simulacro de incendios.

Conceptos básicos de MFA y dónde encaja en tu flujo de inicio de sesión

MFA (autenticación multifactor) significa comprobar que realmente eres tú con dos tipos diferentes de evidencia. Normalmente es una contraseña (algo que sabes) más un código o la aprobación de un dispositivo (algo que tienes). El “segundo factor” es esa comprobación extra. “Step-up auth” (autenticación por elevación) significa que solo pides MFA cuando la acción es riesgosa, como cambiar un correo o ver la facturación. “Recuperación” es la vía de escape si pierdes el factor.

El lugar más seguro para enchufar MFA en un prototipo es después de que el primer paso de inicio de sesión tenga éxito. Eso mantiene intacto tu flujo de contraseña u OAuth existente.

Dónde se sitúa MFA en el flujo

Para inicio por contraseña: el usuario introduce correo y contraseña, los verificas y luego compruebas si MFA está activado. Si lo está, pides TOTP o confirmación por passkey antes de crear la sesión completa.

Para inicio por OAuth (Google, GitHub, etc.): completas el callback del proveedor, encuentras o creas el usuario y luego aplicas MFA antes de emitir la cookie o el token de sesión.

La idea clave: no “medio iniciar sesión” y esperar poder recuperarlo si MFA falla. Decide exactamente cuándo el usuario está completamente autenticado y haz que MFA forme parte de esa decisión.

Qué cambia en tu base de datos

Mantén los datos de MFA separados de los datos de contraseña y trátalos como sensibles.

Normalmente necesitas una bandera simple de habilitado y una marca temporal de enrolamiento, el método elegido (TOTP, passkey, ninguno) y metadatos específicos del método, y el material mínimo necesario para verificar futuros desafíos (por ejemplo, un secreto TOTP encriptado o IDs de credencial de passkey). Añade hashes de los códigos de recuperación (no texto plano), un indicador por código de “usado” y, opcionalmente, un campo como last_mfa_verified_at si planeas forzar reglas de elevación.

Qué registrar para solucionar problemas

Un buen registro te permite depurar bloqueos sin filtrar secretos. Registra eventos como “MFA challenge creado”, “verificación MFA fallida” y “código de recuperación usado”, además de ID de usuario, marca temporal, IP y user agent. No registres códigos TOTP, secretos, códigos de recuperación en bruto ni tokens OAuth completos.

Elegir TOTP vs passkeys para un prototipo

Si estás añadiendo MFA a un prototipo, la elección suele ser entre TOTP (códigos de autenticador) y passkeys (inicio con biometría o dispositivo). Ambos pueden funcionar, pero fallan de formas distintas.

TOTP es el clásico “escribe un código de 6 dígitos”. Los usuarios escanean un código QR con una app de autenticación y luego introducen un código al iniciar sesión. En tu lado, guardas un secreto compartido por usuario (encriptado en reposo) más algunos campos de auditoría como cuándo se activó y cuándo se usó por última vez. Modos comunes de fallo: los usuarios pierden el teléfono, el tiempo del dispositivo está desincronizado, se inscriben dos veces y sobrescriben el secreto, o tu app permite el inicio sin verificar realmente el segundo factor.

Las passkeys se sienten más simples. Los usuarios aprueban con Face ID, huella o PIN del dispositivo. Guardas una clave pública y un ID de credencial, no un secreto compartido. Los fallos cambian: dependencia del dispositivo (sin acceso al dispositivo), configuración cruzada confusa o “funcionó en mi portátil pero no en mi teléfono” si las passkeys no se sincronizan como el usuario espera.

Una regla práctica es simple. Elige TOTP cuando necesites acceso predecible entre dispositivos (administradores, soporte, herramientas B2B) y no puedas asumir dispositivos modernos. Elige passkeys cuando quieras el inicio de sesión más fluido para consumidores y aceptes que la recuperación necesita más cuidado. Soporta ambos si tus usuarios son mixtos, pero mantén la UI enfocada: recomienda un predeterminado (“Usar passkey en este dispositivo”) y ofrece el otro como un respaldo claro (“Usar una app de autenticación en su lugar”).

Ejemplo: una startup de dos personas que lanza un panel de administración interno podría elegir TOTP primero (funciona en todas partes) y luego añadir passkeys para comodidad sin cambiar la política de cuentas admin.

Flujo de enrolamiento que evita bloqueos

El mayor riesgo al enrolar es habilitar MFA demasiado pronto. Si activas la bandera de “MFA habilitado” antes de que el usuario demuestre que realmente puede usarlo, un flujo prototipo puede atraparlo en un bucle: “Introduce código” pero no hay autenticador funcionando, un prompt de passkey que nunca aparece o una sesión que se pierde.

Un patrón seguro es tratar el enrolamiento como una prueba y habilitar MFA solo después de una verificación exitosa. Esa regla sola evita la mayoría de los bloqueos.

Un patrón de enrolamiento a prueba de bloqueos

Mantén el flujo lineal y permisivo. Inicia el enrolamiento mientras el usuario está completamente autenticado (sesión fresca). Déjalo configurar el factor (escanear un QR TOTP o crear una passkey) y luego verifica inmediatamente una vez (introducir un código TOTP o completar la aprobación de la passkey). Justo después, muestra los códigos de recuperación y exige una confirmación explícita como “Los guardé”. Solo entonces marca MFA como habilitado y muestra una pantalla de éxito clara.

Un buen texto reduce tickets de soporte. Sé específico: “Escanea este QR en Google Authenticator o 1Password. Luego introduce el código de 6 dígitos para confirmar. Si cierras esta pestaña antes de confirmar, MFA no se activará.”

Casos límite que debes manejar desde el inicio

TOTP suele fallar por deriva de tiempo. Si se rechaza un código, indica a los usuarios que verifiquen que la hora del teléfono esté en automático y permite un segundo intento antes de forzar un reinicio.

Las passkeys pueden fallar cuando falta el dispositivo o el prompt está bloqueado. Ofrece una ruta alternativa durante el enrolamiento: “¿No puedes usar una passkey ahora? Usa una app de autenticación en su lugar.” Asegúrate de que los códigos de recuperación funcionen incluso si se pierde el dispositivo de passkey.

Códigos de recuperación: configuración, almacenamiento y regeneración

Los códigos de recuperación son la opción de “romper el vidrio” cuando MFA falla: teléfono perdido, app de autenticador borrada o passkey no disponible. Son llaves de repuesto, no un método de inicio habitual. Muéstralos justo después del enrolamiento exitoso y deja claro que ese es el momento para guardarlos.

Mantén el conjunto lo suficientemente pequeño para que la gente realmente lo guarde. Diez códigos de un solo uso es un punto medio común para un prototipo porque cubre unos pocos días malos sin convertirse en una larga lista que ignoren. Usa lenguaje claro como “Guarda esto ahora. No podrás volver a verlo.” Ofrece copiar y descargar, pero exige una comprobación fuerte (contraseña o MFA actual) antes de mostrarlos o regenerarlos.

El mayor error es almacenar códigos de recuperación en texto plano. Guarda solo versiones hasheadas (como las contraseñas) y lleva un registro claro de usados vs no usados para que cada código funcione una vez y luego se queme.

Un modelo de almacenamiento seguro es sencillo: genera 8–10 códigos aleatorios, guarda cada código como un hash más un timestamp used_at (nulo hasta su uso), limita la tasa de intentos y bloquea temporalmente el formulario de recuperación tras fallos repetidos, y registra el uso de códigos de recuperación como un evento de seguridad.

La regeneración debe ser estricta. Cuando un usuario genera nuevos códigos de recuperación, invalida inmediatamente todos los antiguos, incluso los no usados. Advierte claramente: “Tus códigos de recuperación anteriores dejarán de funcionar ahora.” Para mayor seguridad, permite regenerarlos solo después de una comprobación fuerte (MFA actual o inicio de sesión verificado recientemente), de modo que alguien con una contraseña robada no pueda reemplazar discretamente los códigos.

Despliega MFA en fases con rutas de respaldo claras

Intentar imponer MFA con un interruptor grande suele crear una ola de bloqueos. Un despliegue por fases reduce el riesgo y te muestra dónde se atascan los usuarios reales.

Un plan por fases que encaja con la mayoría de apps pequeñas:

• Opt-in: anima a los usuarios a activar MFA después de iniciar sesión, con una opción clara para saltarlo.
• Obligatorio para administradores y personal: protege primero las cuentas de mayor riesgo.
• Obligatorio para todos: solo después de que el enrolamiento y la recuperación sean aburridos y estables.
• Step-up solamente: usa MFA solo para acciones riesgosas (cambiar correo, exportar datos, ver facturación), incluso si el inicio de sesión sigue siendo solo con contraseña.

Cada fase necesita un respaldo seguro, o el soporte se inundará. Apunta a al menos dos formas de volver a entrar: una opción autoservicio y una opción humana.

Rutas de respaldo que evitan bloqueos

Planea estas antes de forzar nada. Los códigos de recuperación son lo mínimo. Un factor de respaldo ayuda también (TOTP más una passkey, o dos passkeys). Si ofreces restablecimientos asistidos por soporte, define comprobaciones de identidad claras y un periodo de enfriamiento antes de eliminar MFA. Un periodo corto de gracia tras el enrolamiento puede reducir falsos bloqueos, pero mantenlo muy acotado (por ejemplo, “saltar una vez”) para que no se convierta en una omisión permanente.

Feature flags y comunicación

Usa un flag de funcionalidad para desplegar primero en cuentas internas, luego a cohortes pequeñas (5%, 20%, 50%). Observa tasa de finalización de enrolamiento, tasa de fallos en desafíos MFA y tickets de “no puedo acceder”.

Diles a los usuarios qué cambia y qué hacer si pierden acceso. Un mensaje corto en la app supera a un anuncio largo: “La próxima semana te pediremos un código extra. Guarda tus códigos de recuperación ahora.”

Haz que los restablecimientos y cambios de cuenta sean seguros con MFA

La forma más fácil de derrotar a MFA es rodearlo mediante cambios de cuenta. Trata los restablecimientos y ediciones de perfil como eventos de seguridad, no simples actualizaciones de formulario.

El restablecimiento de contraseña no debe desactivar MFA

Los restablecimientos de contraseña favorecen a los atacantes porque los buzones se comprometen. Tras un restablecimiento exitoso, mantén MFA activado y exige una comprobación de elevación en el siguiente inicio. Si permites restablecer MFA, conviértelo en una acción separada que requiera un desafío MFA (o un código de recuperación) después de establecer la nueva contraseña.

Una buena regla: cambiar la contraseña puede ayudar a alguien a recuperar el acceso, pero no debería conceder el poder de eliminar MFA.

Protege los cambios de alto riesgo con comprobaciones de elevación

Algunos cambios siempre deberían requerir “pruébalo”: cambios de correo, inscripción de nuevo dispositivo, eliminación o reemplazo de método MFA, cambios de número de teléfono (si usas SMS como respaldo) y actualizaciones de detalles de pago o facturación.

Si un usuario actualiza su correo, envía una confirmación al correo antiguo y mantén el correo antiguo activo hasta confirmar. Si el correo antiguo no está accesible, exige códigos de recuperación y una breve revisión por soporte.

Sesiones, dispositivos recordados y tokens

“Recordar este dispositivo” está bien, pero mantenlo acotado. Fija límites de tiempo claros (a menudo 14–30 días), exige reautenticación para acciones riesgosas incluso en dispositivos recordados y haz que la revocación sea predecible: cierre de sesión global tras un cambio de contraseña, revalidación o revocación de sesiones cuando MFA se habilita o reemplaza, y una lista simple de “sesiones activas” con un botón para revocar.

Para tokens de API e integraciones, decide si están ligados a una sesión de usuario (entonces MFA debe limitar la creación y cambios de alcance) o si son claves de larga duración (entonces confía en scopes estrictos, expiraciones y rotación en lugar de forzar MFA en cada llamada).

Errores comunes que causan bloqueos y avalanchas de soporte

La mayoría de los problemas de MFA no tienen que ver con la matemática. Suceden porque las rutas de “y si no puedo iniciar sesión?” nunca se terminaron.

Error 1: Habilitar MFA antes de que la recuperación sea real

Los equipos publican el prompt de MFA pero dejan los códigos de recuperación sin probar, sin encontrar o rotos en móvil. El resultado son bloqueos instantáneos.

Antes de cambiar cualquier interruptor, prueba la recuperación de punta a punta con una cuenta nueva y un escenario de “teléfono perdido”: genera códigos, usa uno, regenera y confirma que los códigos antiguos dejan de funcionar.

Error 2: Tratar secretos como datos normales

Las semillas TOTP y los códigos de recuperación no son como un nombre de usuario. Si se almacenan en texto plano, se copian en logs o se muestran nuevamente, una fuga se convierte en tomas de cuenta.

Guarda solo lo necesario, protégelo como una contraseña y nunca muestres códigos de recuperación después de la configuración. Si los usuarios los necesitan de nuevo, deben regenerarlos.

Error 3: “Soporte puede simplemente omitirlo”

Un bypass manual de MFA parece útil hasta que se convierte en la vía más fácil para entrar en cuentas. Si necesitas un bypass, hazlo con tiempo limitado, exige pasos de verificación y deja un rastro de auditoría que puedas revisar.

Error 4: Manejo débil de TOTP

Los fallos de TOTP vienen de deriva de reloj, reuso y límites de tasa inexistentes. Aceptar el mismo código dos veces o una ventana de tiempo demasiado amplia facilita el ataque por fuerza bruta y la reproducción.

Mantenlo simple: permite una pequeña ventana de tiempo pero bloquea la reutilización de códigos dentro de esa ventana, limita intentos, usa bloqueos temporales (no ladrillos permanentes) y muestra errores claros para “incorrecto” frente a “expirado”.

Error 5: Asumir que las passkeys se comportan igual en todas partes

Las passkeys pueden fallar de formas inesperadas: cambios de dispositivo, diferencias de soporte en navegadores o usuarios que no tienen una credencial sincronizada. Si tu app requiere passkeys y no ofrece respaldo, bloquearás a usuarios reales.

Mantén un respaldo claro (TOTP o códigos de recuperación) y prueba en al menos un dispositivo iOS, uno Android y un navegador de escritorio.

Lista de comprobación rápida antes de lanzar MFA

Un hábito aburrido te salva después: asegúrate de poder ver lo que pasa y deshacerlo rápido.

Comprobaciones previas al lanzamiento (para poder recuperarte rápido)

Confirma que puedes revertir el cambio de MFA (feature flag, switch de configuración o un deploy rápido). Enciende logs de auditoría para eventos clave como enrolar, verificar, fallo, bloqueo, uso de código de recuperación y deshabilitar. Haz una copia de seguridad de la tabla de usuarios (y cualquier tabla relacionada con MFA) y practica restaurar a una copia segura. Verifica que el seguimiento de errores capture fallos de auth con suficiente detalle para depurar sin registrar secretos ni códigos. Prueba la revocación de sesiones para que cuando cambien ajustes de MFA, las sesiones antiguas se revaliden o cierren.

Luego prueba los recorridos de usuario de punta a punta. No te quedes en “código aceptado”. Sigue el camino completo hasta la primera pantalla posterior al inicio.

Recorridos de usuario y comprobaciones de seguridad

Actúa una pequeña serie de escenarios:

• Un usuario nuevo se enrola en MFA y luego inicia sesión en un segundo dispositivo.
• Un usuario existente habilita MFA, cierra sesión y vuelve a iniciar con dispositivo recordado activado y desactivado.
• Teléfono perdido: un código de recuperación funciona una vez, luego el usuario regenera códigos y vuelve a enrolarse.
• Cambios de correo y restablecimientos de contraseña requieren MFA (o una elevación segura) antes de surtir efecto.
• Resistencia al abuso: límites de tasa en intentos de contraseña e intentos de código MFA, más bloqueos temporales que no bloquee permanentemente la cuenta.

Prepárate para el primer ticket de soporte con un guion corto: qué preguntar, qué verificar en los logs y cuándo escalar.

Ejemplo de despliegue para una app prototipo sencilla

Imagina un pequeño SaaS prototipo: los usuarios inician sesión con correo y contraseña y hay un área de administración para facturación, gestión de usuarios y herramientas de soporte. Quieres más seguridad, pero no puedes arriesgar bloquear a la gente.

Comienza protegiendo las cuentas de mayor riesgo primero (administradores) y luego expande a todos una vez que el flujo sea aburrido y fiable.

Fase 1: TOTP opcional para administradores

Habilita TOTP solo para cuentas admin y mantenlo opcional al principio. Pon el prompt en la configuración de admin, no en medio de un inicio de sesión apresurado.

Una configuración simple: el admin enrola TOTP, la app muestra los códigos de recuperación una vez, el admin confirma un código TOTP y el siguiente inicio de sesión pide contraseña más TOTP. Si TOTP falla, un código de recuperación les permite entrar.

Asegúrate de que siempre haya una forma de volver. Si un admin no puede completar MFA, aún debería poder iniciar sesión con contraseña y contactar soporte (temporalmente) en lugar de quedar bloqueado.

Fase 2: Passkeys para usuarios regulares, TOTP como respaldo

Una vez que los admins estén estables, ofrece passkeys a usuarios regulares como la opción más sencilla. Mantén TOTP disponible como respaldo para personas que no puedan usar passkeys (dispositivos antiguos, equipos compartidos).

Despliega suavemente: comienza ofreciendo “Agregar una passkey” después de iniciar sesión y, más tarde, haz que MFA sea la opción por defecto para nuevos registros.

Un fallo real, manejado con limpieza

Un usuario pierde su teléfono y no puede acceder a TOTP. Inicia sesión con correo y contraseña, elige “Usar un código de recuperación” y entra. Justo después, le pides que registre una nueva passkey (o un nuevo TOTP) y regenere códigos de recuperación. Elimina el método MFA antiguo solo después de confirmar el nuevo.

Próximos pasos y cuándo pedir ayuda

Si quieres MFA sin romper inicios de sesión, empieza con un plan corto que tu equipo pueda compartir: quién recibe MFA primero, cómo alguien inicia sesión si MFA falla y qué significa el éxito (menos inicios de sesión riesgosos, no más tickets de soporte).

Haz un pequeño despliegue interno usando cuentas reales, dispositivos reales y condiciones reales (nuevo teléfono, teléfono perdido, deriva de tiempo, modo de privacidad del navegador). Mantén el piloto lo suficientemente pequeño para que puedas ver cada fallo y arreglarlo rápido.

Decide algunas cosas por escrito antes de activar cualquier interruptor: alcance de la fase 1, opciones de respaldo, qué registras y revisas, quién puede restablecer o anular y qué prueba necesitan, y cuándo empieza la obligatoriedad (más cómo se avisará a los usuarios). Tras el despliegue, vigila la fricción temprano. Picos en errores de “código inválido” suelen apuntar a deriva de tiempo, copy confuso o usuarios que se enrolan en el dispositivo equivocado. Picos en uso de códigos de recuperación pueden significar que la enrolación en passkey o TOTP no se mantiene.

Pide ayuda cuando veas bloqueos repetidos, propiedad poco clara de los flujos de restablecimiento o señales de que tu código de auth es frágil (secretos hardcodeados, sesiones inconsistentes u omisiones extrañas). Si heredaste un prototipo generado por IA, FixMyMess (fixmymess.ai) puede ejecutar una auditoría de código gratuita para identificar los riesgos de bloqueo y los lugares específicos donde tu flujo de autenticación actual puede saltarse o romper MFA antes de imponerlo a todos.