Si el límite de velocidad de inicio de sesión se implementa correctamente, entonces no hay inconvenientes, y debe usarse con o sin 2FA (y de hecho con los mismos intentos 2FA). Y bloqueo de cuenta no es la forma correcta de limitar el número de intentos de inicio de sesión.
La limitación de velocidad significa que restringes el número de intentos que puede hacer una fuente determinada. Por lo general, esto significa una dirección IP determinada, aunque puede definir "fuente", pero tiene sentido en su situación.
En realidad, hay tres tipos de ataques contra los que intenta defenderse:
(a) El atacante conoce la contraseña, en cuyo caso los bloqueos no ayudarán.
un poco.
(b) La contraseña es fácil de adivinar, como "123456" o "passw0rd", o "zxcvbn". Nuevamente, los bloqueos de cuenta no serán útiles porque estos atacantes no intentan más de 5 o 10 contraseñas como máximo antes de pasar a la siguiente cuenta. A menudo intentarán sólo uno. Debe bloquear el atacante , no la cuenta .
(c) El atacante está haciendo una decisión determinada en una sola cuenta de alto valor y probará el diccionario completo y algo más. La contraseña puede no ser fácil de adivinar, pero el atacante tiene todo el mes.
No hay mucho que podamos hacer con respecto a la condición (a) anterior, aunque 2FA puede ayudar. La condición (b) es extremadamente común, mientras que (c) es un poco más rara porque la tasa de éxito es muy baja. Pero, lo que es más importante, ambos pueden frustrarse ralentizando al atacante.
Idealmente, esto no significa un límite estricto de 15, y luego esperas 10 minutos. Lo ideal es hacer un retroceso exponencial. Esto significa que después de 2 intentos, esperas varios segundos. Después del tercero, esperas un poco más. Y luego más largo después del cuarto, y así sucesivamente. El límite se impone en el back-end, y en el front-end usa alguna lógica del lado del cliente como un temporizador en javascript para evitar que el usuario envíe intentos durante el período de espera.
He explicado esta técnica aquí varias veces, para no profundizar en los detalles. Pero lo importante es que es fácil de construir, no molesta a los usuarios legítimos, pero sí funciona muy bien contra determinados atacantes. Al ralentizarlos, está estableciendo efectivamente un límite estricto sobre la cantidad de intentos que pueden realizar en un período de tiempo determinado, pero repartiendo ese límite de manera incremental entre intentos. Y aún mejor, puede detectar qué usuarios continúan enviando intentos durante el período de espera, lo que los marca como que usan software especializado para eludir la limitación de velocidad del lado del cliente. ¡Genial!
Si configura cosas como esta, entonces no hay razón para deshabilitar la limitación de velocidad. No tiene inconvenientes reales, es prácticamente invisible para los usuarios y ofrece una línea de defensa razonable contra los atacantes de fuerza bruta.
Esto solo deja el escenario de un ataque distribuido contra un inicio de sesión único desde una gran botnet. Esto es lo suficientemente raro como para que nunca suceda en la mayoría de los sitios, pero es lo suficientemente simple como para detectar y abordar, así que lo dejaré como un ejercicio para el lector.