Cómo agregar autenticación de dos factores (2FA) a una credencial

Strike puede testear assets protegidos por autenticación de dos factores. Cuando agregas una credencial de tipo User & Password, eliges cómo debe completar Strike el segundo factor: con una app de autenticación (TOTP) o con códigos de verificación por email enviados a una casilla administrada por Strike.

Este artículo cubre los dos métodos soportados, cómo configurar cada uno y las preguntas más frecuentes sobre su setup.

Cómo funciona

La mayoría de las apps en producción requieren 2FA al ingresar. Strike completa el segundo factor de la misma forma que lo haría un usuario real, y después ejecuta el testing autenticado completo sobre tu asset, cubriendo vulnerabilidades que aparecen detrás del login (escalación de privilegios, IDOR, broken access control, fallas de lógica de negocio).

El 2FA es opcional y se configura por credencial. Puedes combinar credenciales con y sin 2FA en un mismo asset, y cambiar el método de una credencial en cualquier momento.

Métodos de 2FA soportados

• App de autenticación: pegas el TOTP secret una sola vez y Strike genera los códigos rotativos de 6 dígitos en cada ejecución.

• Código de verificación por email: la app objetivo envía un código a una casilla @strike.email administrada por Strike; Strike lo lee y continúa el login.

Las casillas @strike.email son buzones reales, entregables, provisionados y leídos por Strike. No necesitas crearlas ni compartir acceso.

Cómo configurar 2FA en una credencial

1. Abre el asset y haz clic en Add credential.

2. Selecciona User & Password como tipo de credencial.

3. Completa el username, la contraseña y el rol esperado.

4. En Advanced configuration, haz clic en Two-factor authentication.

5. Selecciona el Method que use la app objetivo y completa el campo específico de ese método.

6. Haz clic en Save credential.

Puedes editar la configuración de 2FA más adelante haciendo clic en la fila de la credencial para reabrirla. También puedes configurar las credenciales de un asset desde una Threat Emulation, con Set up en el paso de Scoping. Para ver cómo se comparten las credenciales entre el asset y la Threat Emulation, consulta Cómo se hereda la configuración entre un asset y una Threat Emulation.

Método 1: app de autenticación (TOTP)

Usa este método cuando la app objetivo usa Google Authenticator, Authy, 1Password, Microsoft Authenticator o cualquier otra app compatible con TOTP.

Qué necesitas: el TOTP secret de la pantalla de configuración del autenticador de la app objetivo. Es la cadena alfanumérica que suele mostrarse al lado del código QR (por ejemplo, JBSWY3DPEHPK3PXP). Si solo se muestra el código QR, la mayoría de las apps de autenticación permiten ver el secret subyacente después de escanearlo.

Dónde pegarlo: en el campo Authenticator secret que aparece al seleccionar este método.

Eso es todo. Strike genera códigos válidos de 6 dígitos durante toda la ejecución.

Método 2: código de verificación por email

Usa este método cuando la app objetivo envía un código de un solo uso al email del usuario al hacer login (por ejemplo, "Your login code is 123456").

El requisito: el Username de la credencial debe terminar en @strike.email. Strike solo recibe los códigos enviados a casillas que administra, y @strike.email es el dominio que gestiona para este fin.

Si ya tienes una cuenta de prueba en la app objetivo: asegúrate de que su dirección de email termine en @strike.email (por ejemplo, [email protected]). Si no es así, actualiza el email de la cuenta o crea un nuevo usuario de prueba.

Si todavía no tienes una cuenta de prueba: regístrate en la app objetivo usando cualquier dirección @strike.email (por ejemplo, [email protected]). El email de confirmación del registro llega a la casilla administrada por Strike y se lee automáticamente para completar el registro. Después, guarda esas credenciales en Strike usando el mismo username @strike.email.

Cualquier dirección @strike.email funciona sin configuración adicional. No hay casilla que provisionar ni acceso que compartir.

Preguntas frecuentes

¿Puedo usar los dos métodos de 2FA en la misma credencial?

No. Elige el que efectivamente usa la app objetivo. Cada credencial se corresponde con un único flujo de login.

¿Y si no tengo el TOTP secret, solo el código QR?

La mayoría de las apps de autenticación (Google Authenticator, Authy, 1Password) permiten revelar el secret después de escanear el QR. Otra opción es volver a configurar el 2FA en la cuenta de prueba y copiar el secret antes de escanear el nuevo QR.

¿Strike soporta 2FA por SMS?

El soporte de SMS está en expansión. Todavía no hay cobertura de números telefónicos para todos los países, y la lista de regiones soportadas se va actualizando a medida que se suman nuevos proveedores. Si el login de tu asset depende de códigos por SMS, contacta a tu referente de Strike para verificar si tu país está cubierto.

¿Alguien externo a Strike puede ver los emails enviados a @strike.email?

No. Esas casillas están administradas dentro de Strike y no están expuestas externamente. Existen únicamente para recibir emails de verificación y de registro para las Threat Emulations que autorizas.

¿Puedo crear el usuario de prueba con @strike.email antes de configurar Strike?

Sí, y es el flujo recomendado cuando todavía no existe una cuenta de prueba. Regístrate directamente en la app objetivo con cualquier dirección @strike.email; Strike lee el email de confirmación. Después agrega la credencial en Strike usando ese mismo username.

¿Qué pasa si la credencial fue creada por un admin?

Las credenciales provisionadas por el admin del workspace son de solo lectura para el resto de los usuarios. Puedes abrir el panel para inspeccionar la configuración, pero las opciones de edición y eliminación quedan deshabilitadas. Si algo necesita cambiar, contacta a tu admin.

¿La credencial se valida antes de que empiece el testing?

Sí. Al inicio de cada ejecución, el Pre-flight Check verifica que las credenciales configuradas permitan autenticarse. Si el login falla (contraseña incorrecta, secret vencido, código de verificación no recibido), la ejecución no empieza y ves un aviso con el problema. Corrige la credencial y haz clic en Retry. Para más detalle, consulta Cómo funciona el Pre-flight Check.

¿Puedo agregar 2FA a una credencial existente?

Sí. Abre el asset, ve a Details y edita su configuración. Desde ahí puedes abrir la credencial, expandir Two-factor authentication, elegir un método y guardar.

Si el Pre-flight Check falla, ¿se consumen créditos?

No. Si el Pre-flight Check detecta un problema, el testing no llega a iniciar y no se consumen créditos. La idea es justamente detectar y resolver cualquier inconveniente antes de la ejecución, para que no se pierda cobertura ni recursos.