Si su modelo sugiere hacerlo también sin el nombre de usuario;
No puedes hacer esto porque no todos los tokens 2FA son iguales. Cada token es único (clave secreta) y, por lo tanto, debe identificar a la persona que intenta iniciar sesión antes de saber qué token está tratando de verificar.
De la manera en que sugieres que el envío de cualquier código de token se validará de inmediato a un usuario desconocido cuyo token era válido en ese momento, o ninguno, lo cual, en sitios web grandes con muchos cientos de miles de usuarios, aumenta la probabilidad de golpear el Código correcto para cualquiera de esos usuarios. Especialmente porque el 2FA moderno generalmente emplea algún tipo de ventana que permite que los códigos permanezcan válidos antes y después de la iteración correcta actual (lo que representa el sesgo del reloj y otras fuentes de diferencia horaria). Por lo tanto, es probable que cada usuario tenga muchos códigos válidos disponibles a la vez, lo que aumenta aún más las posibilidades de éxito.
No estoy seguro de que puedas retener la información del usuario si escribiera la contraseña incorrecta. Acepto que no envíe un código (en el caso de sms o códigos de correo electrónico), pero si el usuario no entiende que el sitio tuvo un problema, y cuál es ese problema, crea una experiencia frustrante para ellos (ya que señalado en sus contras de la parte 2). Las empresas odian a los clientes frustrados mucho más de lo que odian una menor seguridad.
Por último, esto crearía una forma para que los atacantes ejecuten el spam que proviene de un negocio legítimo en el caso de los códigos de SMS y correo electrónico. Al hacer clic en el botón enviar mi código para todos los códigos, incluso con el enfriamiento, se volverá molesto si sigue apareciendo en cada enfriamiento.
Sin embargo, si en tu modelo sugieres que se requiere el nombre de usuario;
Si se requiere un nombre de usuario y luego el código, y se aplica un período de enfriamiento para evitar ataques, aún así lo desaconsejo. En ese caso, solo con saber el nombre de usuario, puedo ejecutar un DOS en ese usuario, para siempre, con poco o ningún esfuerzo. Simplemente especifique el nombre de usuario y siga enviando los códigos. Cuanto más bajo sea el enfriamiento, mejor será para el usuario, y para el atacante, esencialmente una contraseña de entero entero de 6 u 8 dígitos. Cuanto más largo sea el enfriamiento, peor será para el usuario y mejor para el atacante que realiza un DOS. En ambos casos, el usuario pierde, el atacante gana.
Para resumir todas las razones, creo que internet gravitó hacia este sistema son las siguientes:
- Los sistemas de nombre de usuario / contraseña ya estaban instalados en ese momento y el hardware 2FA fueron los primeros en llegar, lo que significa que era absolutamente necesario saber quién era el usuario primero.
- Las implementaciones de 2FA, incluso aquellas en software (las que se envían al correo electrónico y SMS) a menudo son las mismas metodológicamente que los mandos del teclado. Por lo tanto, tienen el mismo requisito de identificación.
- Los servidores son buenos para manejar una avalancha de solicitudes en el caso de ataques, pero los usuarios finales no lo son.
- Es más sencillo verificar la identidad de alguien con sus credenciales predefinidas directamente con el servidor en lugar de depender de una multitud de sistemas que usted no está seguro de que estén actualmente activos (server01 > sms service > GSM > air > Tower > iPhone > Usuario > internet > ... > server01).