¿Por qué los ataques de descifrado de contraseñas de fuerza bruta no se detectan y frustran automáticamente?

Razonablemente a menudo, lo hacen. Cualquier sistema razonable lo bloqueará si realiza demasiados ataques en línea (o intentos legítimos incorrectos) para acceder a la cuenta.

El problema viene con los ataques sin conexión. El servidor (o lo que esté autentificando también) debe tener algo con lo que comparar la contraseña. Esto suele ser un valor cifrado que se puede descifrar con la contraseña o un hash. Si este valor se ve comprometido, como cuando un atacante obtiene acceso a la base de datos de los usuarios, puede intentar ejecutar el hash o descifrado en su propia computadora y omitir todas las cuentas de cuántas veces se han intentado las cosas. También pueden intentar adivinar órdenes de magnitud más rápido, ya que están trabajando localmente y no tienen que esperar por una red.

Con un ataque fuera de línea, es posible probar miles, si no millones de ataques por segundo, y de repente se vuelve trivial atacar contraseñas simples en minutos, si no segundos. No hay forma de prevenir el ataque ya que no tenemos control sobre el sistema que se usa para verificar la contraseña. Es por esto que es importante cambiar su contraseña después de que se descubre un compromiso con la base de datos.

Para los "ataques en línea", lo hacen, en diferentes grados y con éxito variable. Por lo general, es simplemente una molestia para el usuario legítimo y no un gran impedimento para los delincuentes.
Para los ataques offline es imposible. Si alguien tiene su base de datos de contraseñas, no puede evitar que hagan algo con ella (aunque puede retrasarlas un poco)

Los teléfonos celulares funcionan de la manera exacta que usted describe. Después de ingresar su PIN incorrectamente más allá de algún umbral (por ejemplo, 3 intentos), necesita el PUK para desbloquear el dispositivo. Si eso me pasa alguna vez, estaré muy enojado, ya que tiré el papel donde se anota ese número de 10 dígitos.

Mi enrutador AVM lo bloqueará durante 5 segundos, duplicando la cantidad de tiempo con cada inicio de sesión fallido. Por lo tanto, después de 10 intentos fallidos, debe esperar 42 minutos antes de poder volver a intentarlo.

Sin embargo, tal esquema es moderadamente inteligente. Si bien es poco probable que tenga un error de escritura 10 veces seguidas, es perfectamente posible que no pueda recordar cuál de las 10 contraseñas (contraseñas que usa raramente en una variedad de lugares o entre contraseñas que tiene) cambiado con el tiempo) es el correcto. Además, permite un ataque de denegación de servicio con relativamente poco trabajo.
Por supuesto, el atacante también tiene que esperar entre intentos de inicio de sesión, pero solo espera 21 minutos, donde tendrá que esperar 42 minutos (o 6 horas mientras espera 12). Además, si alguien está siendo malicioso, la espera no duele, siempre puede configurar un despertador a las 6 horas y hacer otro inicio de sesión falso por la noche. Para el usuario legítimo, será un día completo de espera, si esto funciona (y lo que es más importante, la espera hace doler si realmente necesita hacer algo).
Otros sistemas que he visto con algunos sitios web son incluso menos inteligentes. En un caso, hace algunos años, me vi obligado a cambiar mi contraseña para desbloquear mi cuenta porque alguien hizo un par de inicios de sesión falsos. Lo cual es, por supuesto, una tontería total ya que la contraseña demostrablemente no se ha comprometido (ya que estos intentos de inicio de sesión no tuvieron éxito). Esa medida de "seguridad" fue solo una molestia muy grande para el cliente, sin ningún beneficio.

En la defensa de los implementadores, no es nada fácil (si es posible) encontrar algo que funcione mucho mejor.

Hay otro escenario que sería difícil de detectar.

Primero veamos los escenarios contra los que es fácil defenderse;

Fácil: Defensa contra ataque de fuerza bruta en un solo usuario.

Los ataques de fuerza bruta también son fáciles de defenderse, si un solo usuario es el objetivo del ataque. Solo podemos bloquear la cuenta de ese usuario. Esto puede molestar al usuario, pero nos permite evitar que el sistema se vea comprometido.

• iniciar sesión en UserJoe
• iniciar sesión en UserJoe
• iniciar sesión en UserJoe
• iniciar sesión en UserJoe
• iniciar sesión en UserJoe
• Bloquear la cuenta de UserJoe

Fácil: Defensa contra ataque de fuerza bruta desde una sola dirección IP

Ataques de fuerza bruta que son fáciles de detectar y defender, si todas las solicitudes provienen de la misma dirección IP.

Solo podemos impedir que la dirección IP realice más solicitudes.

• SomeIPAddress1 intentando iniciar sesión
• SomeIPAddress1 intentando iniciar sesión
• SomeIPAddress1 intentando iniciar sesión
• SomeIPAddress1 intentando iniciar sesión
• Evite que SomeIPAddress1 intente inicios de sesión futuros

Imposible (?): defensa contra un botnet que fuerza a un nuevo usuario en cada intento.

Supongamos que alguien que usa una red de bots está tratando de forzar la fuerza bruta de su sistema. Tendrán diferentes direcciones IP para que no puedas filtrar los inicios de sesión por dirección IP.

A continuación, supongamos que intentan iniciar sesión con un usuario diferente en cada intento.

Por lo tanto, las solicitudes podrían verse así:

• SomeIPAddress1 intenta iniciar sesión en UserJoe
• SomeIPAddress2 intenta iniciar sesión en UserAnne
• SomeIPAddress3 intenta iniciar sesión en UserMarc
• SomeIPAddress4 intenta iniciar sesión en UserHanah
• ...

No se me ocurre ninguna forma de diferenciar los inicios de sesión legítimos de los inicios de sesión falsos.

Siempre va a ser un acto de equilibrio de cuánto tiempo debe esperar alguien después de un intento de inicio de sesión incorrecto. No es irrazonable seguir aumentando el tiempo de espera después de cada intento (y, finalmente, bloquear otros intentos hasta que se reinicie), pero esto debe estar vinculado a la dirección IP en la que se realiza el intento, para que el usuario legítimo no lo haga. t también queda excluido (victimizado porque alguien está tratando de ingresar en su cuenta). Sin embargo, un ataque distribuido (desde muchas direcciones IP) puede cargar el sistema hasta el punto de que simplemente se convierta en un ataque DDoS simple.

Si alguien está decidido a probar un montón de contraseñas (no necesariamente todas posibles una, solo las más comunes / probables) y tiene una manada de máquinas zombificadas para hacerlo, o bien ' Eventualmente tendré éxito, o llevar el sistema a sus rodillas. No olvide que aplicar un tiempo de espera (rechazar las solicitudes de inicio de sesión) o denegar una dirección IP también consume recursos. ¡Y si tiene tantas contraseñas que no puede recordar cuál utilizar, tiene un problema con su metodología si tiene que revisar todas ellas!

Un desafío de "pregunta de seguridad" (básicamente, una contraseña alternativa) después de tantos intentos fallidos es posible, al igual que enviar una contraseña de un uso (restablecer) a una dirección de correo electrónico registrada (ya sea automáticamente o por solicitud de "contraseña olvidada") , ya que es un bloqueo en esta dirección IP por un tiempo determinado o hasta que se solicite a un administrador que lo desbloquee. He visto todos estos métodos utilizados.

Si el atacante tiene información privilegiada, a saber, el archivo de contraseña cifrado o hash, puede realizar la mayor parte de su trabajo fuera de línea y solo iniciar sesión una vez (después de averiguar la contraseña que debe usar). Las contraseñas siempre deben almacenarse como hashes (encriptaciones unidireccionales), y nunca en texto plano o incluso en una forma encriptada reversible. Los hash son difíciles (pero no imposibles) de recuperar la contraseña de texto sin formato, especialmente si están salados (de modo que el hash no es el mismo para dos usuarios diferentes que eligieron "secreto" para su contraseña).

Porque el cliente no paga por la seguridad.

Necesitas crear una tabla de base de datos. Recopilar direcciones IP de inicios de sesión fallidos. Limpie esta tabla regularmente. Cree otra tabla con direcciones IP bloqueadas y manténgala limpia también. Usted ve que requiere un poco de esfuerzo, y a los clientes no les gusta pagar extra solo por seguridad.

Como desarrollador, debe usar marcos que se ocupen de esos problemas. También es posible que desee consultar fail2ban .