¿Por qué no pedir una contraseña y un token de 2 factores al mismo tiempo?

Muchos sistemas OTP le permiten recibir un OTP por SMS / correo electrónico. Por lo tanto, el sistema debe saber cuándo enviarle una OTP.

Puede sugerir que podría haber un botón "solicitar OTP" junto al formulario. Pero luego cualquiera puede hacer clic repetidamente en el botón, lo que significa que recibirá una gran cantidad de correo electrónico no deseado / SMS.

Puede sugerir que se solucione ese problema limitando la tasa de OTP. Pero luego puedo provocarle una denegación de servicio solicitando su cuota completa de OTP para que no pueda iniciar sesión.

Una solución simple para esto es enviar solo una OTP a un usuario que haya proporcionado una contraseña válida.

No veo ningún problema de seguridad al solicitar la contraseña y un segundo factor (token / biométrico) al mismo tiempo.

De hecho, esto aumenta la seguridad del sistema, pero puede afectar la usabilidad (experiencia del usuario) del sistema. ¿Cómo es eso?

Digamos que el sistema toma los dos factores de autenticación (contraseña y OTP) en el mismo punto y los prueba. si ambos coinciden / pasan, permiten el acceso; de lo contrario, denegará el acceso.

supongamos que hay 100 contraseñas posibles y 200 códigos OTP posibles.

Si primero solicita la contraseña en un punto y luego, cuando se recibe una contraseña válida, solicita la OTP, entonces el atacante debe intentar 300 veces (100 + 200) para ingresar al sistema. .

Pero si solicita la contraseña y la OTP al mismo tiempo, el atacante deberá intentar 20000 veces (100 * 200) para ingresar al sistema.

Ahora, desde el punto de usabilidad, si el usuario ingresó una contraseña incorrecta o un código OTP, el sistema no le dirá exactamente qué salió mal y podría seguir cometiendo el mismo error, por ejemplo, ingresando la contraseña incorrecta porque cree que es correcta, el problema real con su token OTP o al revés.

Podría haber una serie de razones no técnicas, posiblemente un controlador sería el rendimiento porque reduce la carga a algunos procesos en el servidor que no necesitan ser llamados.

Otra posibilidad puede ser dificultar la configuración de un sitio web de phishing. Ahora necesitas programar varias páginas. Además, si solo muestra OTP cuando hay un nombre de usuario y contraseña exitosos (algo que usted conoce como autenticación) puede dificultar la creación del sitio de phishing y proporciona más páginas para que el usuario lo note. Las imágenes de seguridad a menudo se consideran de valor mínimo porque el proceso suele ser un nombre de usuario, luego muestra la imagen de seguridad (por ejemplo, SiteKey ), luego contraseña. Sin embargo, si solo cambia esto con dos factores para ser nombre de usuario- > contraseña- > imagen de seguridad- > OTP, esto hace que la creación de un sitio de phishing sea más compleja, aunque no es imposible ya que el sitio de phishing puede emular una sesión de usuario para el sitio real con el nombre de usuario y la contraseña.

Las siguientes preguntas abordan la propagación de un inicio de sesión en varias páginas en general:

• Qué ¿Cuáles son los beneficios de un sistema de inicio de sesión de dos páginas para una aplicación web?
• Inicio de sesión de dos páginas para evitar la exposición accidental de contraseñas

La razón por la que decidimos no solicitar claves de autenticación de dos factores al mismo tiempo no tenía nada que ver con la seguridad. Resulta que solicitar una contraseña única al mismo tiempo que el nombre de usuario y la contraseña normales puede provocar un mal comportamiento de autocompletado con varios complementos, scripts y amp; navegadores.

Esta es una razón UX en lugar de seguridad, pero lo suficientemente importante como para ser la razón de este estándar.

"Un formulario de inicio de sesión podría detectar un nombre de usuario que tiene habilitada la autenticación de 2 factores": ¿cómo?

Para hacer esto, la página tendría que enviar otra solicitud al servidor, incluido el nombre de usuario (que parece ser lo que estás tratando de evitar), o la página tendría que incluir una lista de todos los nombres de usuario con autenticación de 2 factores habilitados en el cuerpo de la página de inicio de sesión original (no es una buena idea).

Hay ventajas en este caso específico para mantener si la autenticación de 2 factores está habilitada en secreto hasta que la contraseña se haya ingresado correctamente, especialmente en el caso de tokens enviados por mensaje de texto, por ejemplo. Si un 'malo' logra encontrar su nombre de usuario y contraseña para el sitio, es posible que no sepan si la autenticación de 2 factores está habilitada. Esto significa que pueden intentar iniciar sesión y hacer que el servicio le envíe un mensaje de texto, avisándole que su contraseña ha sido comprometida e impedir que puedan acceder a su cuenta. Si pueden saber de inmediato si su cuenta tiene habilitada la autenticación de 2 factores, no correrían ese riesgo.

Yo diría que esto es una limitación del tipo de autenticación utilizada. Un sistema push, dial-back o basado en SMS (por ejemplo: Duo, PhoneFactor) es solo un factor: posesión del dispositivo, por lo tanto, el usuario también debe ingresar algo que sepa primero que inicia la solicitud. Dado que cada solicitud cuesta dinero (ya sea para usted o para el servicio o para ambos), quieren lo menos posible.

Otros sistemas incluyen ambos factores en uno. Con Securid, el PIN se adjunta a la OTP y se ingresa una vez. Con WiKID, el PIN se ingresa en el token para obtener la OTP, por lo que solo se debe ingresar la OTP.