
Con las transacciones digitales haciéndose comunes y los ciberataques aumentando, la importancia de métodos de autenticación fuertes nunca ha sido mayor. Un método de autenticación de dos factores ampliamente utilizado es SMS Una sola vez la contraseña (OTP).
¿Qué es SMS OTP?
SMS OTP envía un código alfanumérico o numérico único a un número móvil para la autenticación de dos factores. Los destinatarios utilizan este código cuando inician sesión en un servicio, sitio web o aplicación. Sin embargo, este método tiene vulnerabilidades. En este blog, explicaremos por qué la verificación de SMS OTP no es segura y mostraremos en detalle uno de los ataques que podrían ocurrir al usar SMS OTP.
Tipos de ataques de phishing por SMS OTP
Una grave debilidad de SMS OTP es su susceptibilidad a ataques de phishing y tácticas de ingeniería social. Phishing engaña a los usuarios para que den información sensible haciéndose pasar por fuentes legítimas. Los atacantes pueden hacer sitios o aplicaciones falsas para robar credenciales y OTPs. La ingeniería social, como la suplantación, también puede hacer que los usuarios compartan OTPs por teléfono. Una vez que los atacantes tienen OTPs, pueden romper cuentas y acceder a datos confidenciales.
Aquí están los tipos 3 de ataques de phishing de SMS OTP
Intercepción y conmutación SIM: Los OTPs SMS se pueden interceptar a través de intercambio SIM o vulnerabilidades de red. Los atacantes obtienen el control de los números de las víctimas, interceptan los OTP y las cuentas de incumplimiento.
Phishing & Ingeniería Social: Los SMS OTP son susceptibles a ataques de phishing. Los atacantes engañan a los usuarios para que revelen los OTP a través de sitios falsos o tácticas de ingeniería social, comprometendo cuentas.
Riesgos de dispositivos y redes: Robo de dispositivos móviles o vulnerabilidades de red exponen OTPs. Incluso los dispositivos seguros son vulnerables a los ataques basados en la red, lo que compromete la integridad de la autenticación.
Ejemplo de ataque de phishing de SMS OTP
El ataque comienza con un correo electrónico enviado a un usuario que pide que se restablezca la credencial o que el usuario inicie sesión en su cuenta para verificar alguna actividad. El enlace en el correo electrónico dirigirá al usuario a un sitio de phishing que se configura para parecerse al sitio legítimo real.

El usuario introduce sus credenciales en el sitio de phishing. Las credenciales son registradas por el hacker, y posteriormente introducidas en el sitio legítimo por el hacker.

El sitio legítimo genera una contraseña SMS única (OTP), y la envía al usuario, generalmente en forma de una cadena de caracteres alfabéticos o un código numérico de seis u ocho dígitos.

El usuario introduce manualmente OTP en el sitio de phishing, y el atacante introduce OTP en el sitio legítimo, obteniendo así acceso.

El hacker ha pasado fácilmente por alto las protecciones adicionales de SMS en esencia de la misma manera en que el nombre de usuario original y la contraseña fueron comprometidos. Le preguntaron al usuario por sus secretos. Hay variaciones mucho más sofisticadas de este ataque, pero porque el hacker puede simplemente pedir al usuario la sofisticación de la información no es necesario.
¿Cómo proteger contra los ataques de phishing?
Para prevenir ataques de phishing y proteger a los usuarios contra ataques de phishing, es crucial fortalecer el proceso de autenticación permitiendo la autenticación multifactor sin contraseña (MFA) como PasswordFree® by Identite. PasswordFree realiza 3FA con dos toques en una pantalla. Los usuarios pueden iniciar sesión en cuentas en menos de 5 segundos y estar totalmente protegidos contra ataques cibernéticos. ¿Quieres saber más sobre PasswordFree® MFA? Descúbrelo aquí.
Además, Identité® tiene un galardonado método patentado de autenticación de dos vías Full Duplex Authentication® (FDA). FDA realiza una secuencia de autenticación única y altamente segura mediante la cual el servidor envía metadatos al dispositivo de usuario, para que el servidor pueda completar la validación de la solicitud de autenticación.
Sin embargo, la clave privada del usuario aún no se invoca. El servidor se valida al usuario enviando tanto el contexto estático como el dinámico necesario para demostrar su identidad a la aplicación móvil. Sólo entonces la aplicación móvil invoca la clave privada del usuario para autenticarse.

