Para sistemas donde 2FA / MFA es "opcional" como Gmail o Outlook.com, el servicio debe equilibrar el factor de molestia de usar el método de 2 factores y la seguridad que trae a su sitio . En un mundo perfecto, los usuarios tendrían contraseñas complejas y únicas para cada sitio, y siempre usarían 2FA cuando estén disponibles, pero en el mundo real, tiene razón: los usuarios tendrán la misma contraseña en una docena de sitios y un factor de 2. Un mecanismo que no bloquea automáticamente la cuenta y notifica al usuario después de unos pocos intentos de inicio de sesión no válidos en una ventana relativamente pequeña podría llevar a una situación en la que el atacante intenta pacientemente algunas conjeturas hasta llegar al indicador 2FA, momento en el que Sé que tienen una combinación válida de nombre de usuario y contraseña. Con todas las bases de datos de contraseñas altamente públicas en sitios grandes (como LinkedIn, entre muchos otros) que usan su dirección de correo electrónico como inicio de sesión, un atacante puede adivinar lógicamente la contraseña de un usuario con relativa facilidad si el usuario nunca se molestó en actualizar otros sitios. , pero solo la que estaba "rajada".
Para aplicaciones críticas para la seguridad (como una de varias en las que trabajo), el indicador de inicio de sesión requiere un nombre de usuario, contraseña y valor de 2 factores, todo al mismo tiempo, y es una autenticación de "todo o nada", y no lo hacemos. t le dice POR QUÉ falló su inicio de sesión, a menos que sea porque su contraseña ha caducado (lo que supone que ingresó la contraseña correcta, pero solo va a requerir que la cambie e ingrese nuevamente con otro valor 2FA para obtener acceso a la aplicación) . Esa aplicación tiene una base de usuarios "cautiva" y la política lo requiere 2FA, por lo que no es directamente comparable con los sitios "2FA opcionales" que mencionó en el OP.
Fundamentalmente, sin embargo, estoy de acuerdo con los comentarios anteriores de que un "token-on-demand" es más seguro que un token "offline" (como RSA o Google Authenticator) si va a realizar la autenticación de 2 pasos porque el usuario sabrá de inmediato que alguien está intentando acceder a su cuenta en virtud de mensajes SMS inesperados, ya sea una "contraseña incorrecta" o una cadena de 2 factores válida en caso de que el atacante lo haga correctamente. Si el sitio SOLAMENTE envía el valor de factor 2 de SMS al iniciar sesión correctamente, entonces es inútil para el punto que menciona, al informar al usuario ANTES de que el atacante realmente obtenga la contraseña correcta. El usuario solo obtendría la cadena válida de 2 factores cuando el atacante tenía la contraseña correcta. Para entonces, es probable que sea demasiado tarde, y el atacante ya está intentando probar las mismas combinaciones de nombre de usuario y contraseña en otros sitios que no tienen 2FA y el usuario tendría que estar en una computadora y luchando para cambiar cada contraseña en cada sitio lo usan, y si reutilizan la misma contraseña en todas partes, es prácticamente imposible porque no los recordarán todos.
En última instancia, depende de la implementación individual en cuanto a lo dañino que puede ser un 2FA para los otros sitios utilizados por el mismo usuario. En el mejor de los casos, es un inicio de sesión todo en uno como describí, donde el atacante también tendría que tener de alguna manera su dispositivo 2FA o "cadena mágica" (token de inicialización para algo como Google Authenticator), y si lo tienen también , el usuario ya ha sido bien comprometido.
