No especificó si está preguntando sobre un ataque en línea o un ataque fuera de línea.
Tampoco dijo si quiso decir desde el punto de vista de un diseñador de servicios o desde el punto de vista de un usuario. Desde el punto de vista del usuario, la respuesta es usar una contraseña segura y única. También un usuario puede considerar habilitar alguna verificación de segundo factor si está disponible para el servicio en particular.
Para el resto de esto, voy a discutir qué pueden hacer los diseñadores de servicios para defenderse de los ataques de contraseña de fuerza bruta.
- Cómo hackear un sistema de seguridad comercial
- ¿Cómo fue hackeado Twitter el 2012/05/08 /?
- ¿Qué es el "dorking de Google" y cuál es la defensa contra este problema?
- ¿Cuál es el mejor lenguaje de programación para hackear y por qué?
- ¿Por qué no se ha eliminado la cuenta de Twitter de LulzSec?
Ataques de fuerza bruta en línea
Un ataque de fuerza bruta en línea es cuando el atacante realiza múltiples intentos de inicio de sesión en el servidor legítimo. Puede ser un servidor web y un servidor de correo electrónico, un servidor de aplicaciones de iCloud o lo que sea.
Hay varias cosas que un servidor puede hacer para frustrar tales ataques. Por lo general, estos se realizan en combinación entre sí.
Limitación de velocidad
Usar alguna forma de limitación de velocidad es posible. Por ejemplo, después del primer intento fallido de un nombre de usuario, puede requerir que transcurra un segundo antes de que se pueda enviar un segundo intento para ese nombre de usuario. Luego, simplemente duplique eso por cada intento fallido posterior.
Hay otros esquemas de limitación de velocidad disponibles. Realmente no tengo opiniones firmes sobre cuáles son los mejores, porque casi siempre y cuando tengas algo razonable, funcionará tan bien como todos los demás métodos razonables.
Cerrar
Esto es como limitar la velocidad extrema. Después de un cierto número de intentos fallidos, el servidor deshabilita (bloquea) todos los inicios de sesión de la cuenta. El propietario legítimo de la cuenta tendrá que pasar por un procedimiento separado para desbloquear la cuenta.
Una dificultad con esto es que el procedimiento de desbloqueo por el que alguien tiene que pasar a menudo tiene una seguridad peor que la contraseña original. En particular, las “preguntas de seguridad” como “cuál es el segundo nombre de su padre” a menudo se basan en información disponible públicamente.
Notificación
Un servicio puede intentar notificar al usuario legítimo de intentos fallidos (o exitosos) de inicio de sesión. Por ejemplo, cada vez que inicio sesión en mi proveedor de alojamiento DNS, se me presenta algo como
Último inicio de sesión desde 72.64.118.114 el 03-feb-2014 18:36:34 Último inicio de sesión fallido: 72.64.118.114 el 10-sep-2013 13:24:53
iCloud notifica a todos mis dispositivos registrados cada vez que se registra un nuevo dispositivo para mi cuenta de iCloud. Otros sistemas enviarán correos electrónicos o mensajes de texto cuando haya un inicio de sesión desde un nuevo dispositivo o si hay un cierto número de intentos fallidos.
Exactamente, la mejor manera de ajustar dicha notificación es complicada y debe hacerse caso por caso. Si le das a la gente información sobre la que no pueden actuar fácilmente, no les estás haciendo ningún favor. Por lo tanto, estas cosas deben diseñarse con mucho cuidado.
Ataques de fuerza bruta fuera de línea
Un ataque fuera de línea es cuando el atacante ha capturado los datos de la contraseña hash de alguna parte. Una vez que el atacante tiene estos datos, no necesita comunicarse con el servidor en absoluto, por lo que todos los métodos utilizados para defenderse contra los ataques en línea ya no se aplican.
No permita que los atacantes obtengan datos de contraseña
La defensa obvia es no permitir que los atacantes obtengan los datos de la contraseña hash. Obviamente, las personas intentan diseñar sistemas con esto en mente, pero igual de obvio, estas cosas fallan.
Buen hashing de contraseña
Por lo tanto, además de lo obvio, se recomienda encarecidamente que los servidores que almacenan contraseñas hash las utilicen de manera que sean computacionalmente caras de verificar.
Antecedentes sobre hashing
La idea (relevante) de una función hash criptográfica es que si c = H (m), no es factible averiguar qué es m simplemente conociendo c y la naturaleza de la función hash, H.
Entonces, por ejemplo, si usamos la función hash SHA1 en “Contraseña1” obtenemos … 70ccd9007338d6d81dd3b6271621b9cf9a97ea00 (bytes codificados como hexadecimales).
La idea es que es computacionalmente inviable pasar de ese número a “Contraseña1”. Entonces, en cambio, lo que hará un ataque de fuerza bruta es calcular el hash de muchas contraseñas comunes y ver si alguna de ellas resulta ser la misma que algunos de los hashes de contraseñas que han robado.
Una PC de gama alta puede calcular muchos millones de hash SHA1 por segundo.
Saca tus contraseñas / hashes
No voy a explicar o discutir la salazón, aparte de decir que hay que hacerlo. Entonces, cuando el servidor crea un hash de contraseña para una contraseña, necesita sal.
Hash lento
Como dije, una PC de gama alta puede realizar muchas decenas o incluso cientos de millones de hash SHA1 por segundo. Las funciones hash criptográficas cumplen muchas funciones y queremos que sean rápidas. La velocidad de SHA1 (y otras funciones hash criptográficas) es algo bueno en general. Simplemente significa que no son ideales para contraseñas hash.
Lo que nos gustaría hacer es reducir la tasa de conjeturas en un ataque fuera de línea de, digamos, cientos de millones de conjeturas por segundo a algo más como unas pocas decenas de miles de conjeturas por segundo.
Actualmente hay tres algoritmos de “hash lento” en uso para hacer esto. Cada uno usa “hashes rápidos” internamente, pero ellos mismos son “lentos”. Estos tres son PBKDF2, bcrypt y scrypt. Si está creando un servidor que necesita verificar las contraseñas, aprenda a usar una de ellas y úsela.
Podría seguir hablando mucho sobre los méritos relativos de esos tres esquemas de hashing de contraseñas, pero eso distraería del punto de que cualquier cosa que procese las contraseñas debería usar una de ellas (y usarla correctamente). La comunidad de seguridad no está completamente satisfecha con ninguno de esos tres, y es por eso que hay un esfuerzo para desarrollar un sucesor de esos esquemas. Vea la Competencia de hash de contraseña para más detalles.
