¿Puedo ralentizar un ataque de fuerza bruta al codificar los datos de entrada de contraseña?

Question

¿Puedo ralentizar un ataque de fuerza bruta al codificar los datos de entrada de contraseña?

#1 de Arminius (6 votos)
#2 de John Wu (4 votos)
#3 de Benoit Esnard (1 votos)

3

Estoy creando un formulario de inicio de sesión de php con solo un username & password como $ _POST datos. Pero antes de enviar el formulario, una función JS check() basará en base64 la entrada password , y finalmente enviará el formulario de esta manera: (la función base64_enc personalizada es un poco más avanzada que solo una codificación base64)

function check() {
   var pwd = $_get_by_id('loginPw').value;
   $_get_by_id('loginPw').value = base64_enc(pwd);
   $_get_by_id('loginFrm').submit();
}

Por supuesto, además de eso, sé que tenemos una gran cantidad de elementos de seguridad para evitar la fuerza bruta (id de sesión, token csrf, captcha, ban de tempo ...).

Pero me pregunto si, en este punto, ¿este simple truco de JavaScript podría ralentizar un ataque? (Incluso el atacante debe generar otra versión procesada de sus diccionarios)

Por ejemplo, si la herramienta hydra puede procesar cada línea de la lista de palabras antes de ejecutar un hilo (con una versión de código de shell de lo que tenemos en el control de javascript () fn)

brute-force cryptography hydra

pregunta The-Vinh VO 21.04.2017 - 19:37

fuente

3 respuestas

4

No, esta idea no ralentizará a un atacante, porque la contraseña codificada es la contraseña: es el valor que un cliente HTTP necesita para acceder al sistema. La contraseña original es casi incidental en ese punto. En cambio, el pirata informático centrará su atención en iterar a través de cadenas Base64 en lugar de contraseñas, y la entropía total será exactamente la misma. Además, si el pirata informático tiene un diccionario de contraseñas, es trivial generar un diccionario de cadenas Base64 que comprenda la misma lista.

Sin embargo, no es una idea terrible frenar a un atacante pidiéndole que resuelva un problema complejo. CAPTCHA es el ejemplo más común: las herramientas piratas pueden descubrir cómo resolver un CAPTCHA, pero requiere un poco de CPU y reducirá el número de intentos de fuerza bruta por segundo. Resolver cualquier problema complejo haría lo mismo, por ejemplo, si además de enviar la contraseña, el script también tenía que adivinar el valor detrás de un hash (basado en un valor aleatorio y no relacionado) proporcionado por el servidor. Pero desearía mantener ese mecanismo completamente separado de la contraseña.

respondido por el John Wu 21.04.2017 - 20:20

fuente

1

No le cambiará nada al atacante. Ni siquiera necesitará actualizar sus diccionarios.

El ataque genera contraseñas y las envía a una función que realizará la solicitud HTTP. El atacante tiene que seleccionar la URL a la que apuntar, nombrar los parámetros. Codificar la contraseña en esa función no es lento. Son órdenes de magnitud más rápidas que la solicitud HTTP, y el impacto en el tamaño de la solicitud será tan pequeño que no tendrá ningún efecto.

respondido por el Benoit Esnard 21.04.2017 - 19:47

fuente

Lea otras preguntas en las etiquetas brute-force cryptography hydra

¿Cómo entender "Datos cifrados" en el tipo de mensaje TLS? ¿Es posible el conocimiento cero con los servicios de correo electrónico cifrado basados en web?

score 6 · Accepted Answer

¿Puedo reducir la velocidad de un ataque de fuerza bruta al codificar los datos de entrada de contraseña?

Sí, puede ralentizar artificialmente un ataque de fuerza bruta haciendo que el cliente realice una tarea costosa para cada intento de inicio de sesión. Este concepto se denomina prueba de trabajo . Es un método bien conocido para combatir el spam masivo y, técnicamente, también podría aplicarlo a los sistemas de autenticación en la web.

Sin embargo , su propuesta concreta no calificaría como un protocolo de prueba de trabajo. Esto se debe a que base64 no es caro en absoluto y requiere una cantidad igual de trabajo para que el cliente lo genere, al igual que lo hace para que el servidor lo verifique. Además, un atacante podría reutilizar las contraseñas codificadas tantas veces como lo deseen sin tener que volver a calcularlas, por ejemplo. para atacar otras cuentas.

Para una implementación real de prueba de trabajo, podría, por ejemplo, cree un esquema de desafío-respuesta y solicite al usuario que realice cálculos de hash costosos en cada intento de inicio de sesión. El desafío podría ser invertir parcialmente un hash: proporciona una secuencia aleatoria y desafía al usuario a generar un hash SHA-256 que termina con esa misma secuencia. Aumentar la longitud de la secuencia requiere de manera exponencial más cálculos de hash por parte del cliente, pero verificar los resultados siempre es solo una comparación de cadenas.

El proyecto "inicio de sesión de prueba de trabajo" es uno de los pocos He encontrado ejemplos que recogen la idea de usar un POW para los inicios de sesión. (No puedo comentar sobre la calidad de la implementación). De la descripción:

Debe calcularse un hash SHA256 del lado del cliente antes de permitir un inicio de sesión. Esto limita los ataques de inicio de sesión de bruteforce en entornos donde no se puede prohibir por IP como los Servicios Ocultos.

Sin embargo, debe tener en cuenta que, para las aplicaciones web, existen medios más simples para obstaculizar los ataques de fuerza bruta, como los CAPTCHA, que limitan los intentos de inicio de sesión por cuenta, las IP de listas negras, etc.