¿Sigue siendo necesario limitar el inicio de sesión si empleamos la autenticación multifactor?

5

El status quo es que la mayoría de los sitios web en línea limitan los intentos de inicio de sesión por dirección IP, o incluso por cuenta, ya que algunos atacantes poseen enormes cantidades de direcciones IP.

Eliminar los límites de inicio de sesión tendría la ventaja de que los atacantes ya no podrían denegar el acceso de manera fraudulenta ( disponibilidad ) para usuarios legítimos, ya sea por dirección IP o por cuenta. OWASP declara :

  

Cuando se implementa Multifactor y está activo, es posible que el bloqueo de la cuenta ya no sea necesario.

¿Qué tan cierta es esta afirmación? ¿Significa que si nuestro sitio web emplea una autenticación multifactor obligatoria (por ejemplo, Google Authenticator ), podemos eliminar nuestro " ¿Límite de inicio de sesión de dirección IP "y mecanismo de" límite de inicio de sesión por cuenta "?

¿Todavía es posible la fuerza bruta mediante la autenticación multifactor si no hay límites de inicio de sesión?

    
pregunta Pacerier 07.06.2014 - 07:02
fuente

3 respuestas

5

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 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.

    
respondido por el tylerl 07.06.2014 - 09:53
fuente
1

Si el 100% de su base de usuarios utiliza 2FA en todos los inicios de sesión, es posible que no sea tan importante, sin embargo, es posible que aún tenga que limitar el número de intentos de 2FA como mínimo. Algunos servicios solo utilizan un código de 4 dígitos enviado por SMS con una ventana de 5 minutos, en cuyo caso es posible que un atacante pudiera forzar el código. En otras palabras, es probable que aún necesites limitar la tasa en algún lugar para evitar ser menos seguro.

Aun así, recomendaría un límite de velocidad tanto para los inicios de sesión como para 2FA:

  • Las funciones criptográficas suelen ser costosas desde el punto de vista informático, por lo que un atacante podría montar un ataque de DOS realizando un alto volumen de solicitudes de inicio de sesión no válidas.
  • No sabes si tu dispositivo de usuario ha sido comprometido o ha sido robado, los atacantes aún pueden intentar un ataque de fuerza bruta en ese momento.
  • Por lo general, 2FA es opcional, por lo que es raro tener una inscripción del 100% y, de lo contrario, aún sería necesario calificar a los usuarios sin 2FA.
respondido por el thexacre 07.06.2014 - 07:53
fuente
1

También recomiendo la limitación de velocidad. Es mejor vigilar las cosas.

Esto es lo que hacemos en el servidor WiKID. El servidor bloqueará al usuario después de un número de intentos de contraseña incorrectos (configurables por el administrador), pero ignorará las contraseñas no numéricas. Esto evita que un usuario quede bloqueado por un simple intento de fuerza bruta pero lo protege de que alguien adivine códigos.

Creamos una entrada de registro en la que se intentó un código de acceso no numérico. Recomendamos revisarlos para ver si el atacante está utilizando una credencial robada válida.

(Tenga en cuenta que algunos tokens basados en el tiempo o en el contador pueden configurarse de modo que más de un código de acceso pueda ser válido en un momento dado para permitir la sincronización del reloj / la deriva del contador)     

respondido por el nowen 09.06.2014 - 16:13
fuente

Lea otras preguntas en las etiquetas