Esta pregunta siempre me ha preocupado.
En Linux, cuando se le solicita una contraseña, si su entrada es la correcta, la verifica de inmediato, casi sin demora. Pero, por otro lado, si escribe la contraseña incorrecta, la verificación demorará más. ¿Porqué es eso?
Observé esto en todas las distribuciones de Linux que he probado.
Respuestas:
En realidad, es para evitar que los ataques de fuerza bruta prueben millones de contraseñas por segundo. La idea es limitar la rapidez con la que se pueden verificar las contraseñas y hay una serie de reglas que deben seguirse.
Ese último es particularmente importante. Significa que no hay mensajes útiles como:
Your user name is correct but your password is wrong, please try again
o:
Sorry, password wasn't long enough
Ni siquiera una diferencia de tiempo en la respuesta entre el "usuario y contraseña inválidos" y "usuario válido pero contraseña inválida".
Cada falla debe entregar exactamente la misma información, textual y de otro tipo.
Algunos sistemas lo llevan aún más lejos, aumentando la demora con cada falla, o solo permiten tres fallas y luego tienen una demora masiva antes de permitir un reintento.
Esto hace que se tarde más en adivinar las contraseñas.
No estoy seguro, pero es bastante común integrar un retraso después de ingresar una contraseña incorrecta para dificultar los ataques. Esto hace que un ataque sea prácticamente inviable, porque le llevará mucho tiempo comprobar solo unas pocas contraseñas.
Incluso probar algunas contraseñas (fechas de nacimiento, el nombre del gato y cosas así) no resulta divertido.
123456 podría representar el 30% (por ejemplo) de las cuentas comprometidas, pero es poco probable que sea tan significativo en todas las cuentas.
Básicamente para mitigar la fuerza bruta y los ataques de diccionario.
De la Guía del desarrollador de aplicaciones Linux-PAM :
Planificación de retrasos
extern int pam_fail_delay(pam_handle_t *pamh, unsigned int micro_sec);Linux-PAM ofrece esta función para facilitar los retrasos de tiempo después de una llamada fallida a pam_authenticate () y antes de que se devuelva el control a la aplicación. Al utilizar esta función, el programador de la aplicación debe comprobar si está disponible con,
#ifdef PAM_FAIL_DELAY .... #endif /* PAM_FAIL_DELAY */Generalmente, una aplicación solicita que un usuario sea autenticado por Linux-PAM a través de una llamada a pam_authenticate () o pam_chauthtok (). Estas funciones llaman a cada uno de los módulos de autenticación apilados enumerados en el archivo de configuración de Linux-PAM relevante. Como se indica en este archivo, uno o más de los módulos pueden fallar y provocar que la llamada pam _... () devuelva un error. Es deseable que también haya una pausa antes de que continúe la aplicación. La razón principal de tal retraso es la seguridad: un retraso actúa principalmente para desalentar los ataques de diccionario de fuerza bruta, pero también ayuda a obstaculizar los ataques temporizados (canal encubierto).
Es una forma muy sencilla y prácticamente sin esfuerzo de aumentar considerablemente la seguridad. Considerar:
El sistema Ano tiene demora. Un atacante tiene un programa que crea combinaciones de nombre de usuario / contraseña. A una velocidad de miles de intentos por minuto, solo se necesitan unas pocas horas para probar todas las combinaciones y registrar todos los inicios de sesión exitosos.
El sistema Bgenera un retraso de 5 segundos después de cada suposición incorrecta. La eficiencia del atacante se ha reducido a 12 intentos por minuto, paralizando efectivamente el ataque de fuerza bruta. En lugar de horas, puede llevar meses encontrar un inicio de sesión válido. Si los piratas informáticos fueran tan pacientes, serían legítimos. :-)
Los retrasos de autenticación fallidos están ahí para reducir la tasa de intentos de inicio de sesión. La idea de que si alguien está probando un diccionario o un ataque de fuerza bruta contra una o varias cuentas de usuario, se requerirá que el atacante espere el retraso de la falla y, por lo tanto, lo obligará a tomar más tiempo y le dará más posibilidades de detectarlo.
También puede interesarle saber que, dependiendo de lo que esté usando como shell de inicio de sesión, generalmente hay una forma de configurar este retraso.
En GDM, el retraso se establece en el archivo gdm.conf (generalmente en /etc/gdm/gdm.conf). debe establecer RetryDelay = x donde x es un valor en segundos.
La mayoría de las distribuciones de Linux en la actualidad también admiten la definición de FAIL_DELAY en /etc/login.defs, lo que le permite establecer un tiempo de espera después de un intento fallido de inicio de sesión.
Finalmente, PAM también le permite establecer un atributo nodelay en su línea de autenticación para evitar el retraso de falla. ( Aquí hay un artículo sobre PAM y Linux )
No veo que pueda ser tan simple como sugieren las respuestas.
Si la respuesta a una contraseña correcta es (algún valor de) inmediata, ¿no solo tiene que esperar hasta que supere ese valor para saber que la contraseña es incorrecta? (al menos sepa probabilísticamente, lo cual está bien para propósitos de craqueo) Y de todos modos estaría ejecutando este ataque en paralelo ... ¿es todo esto un gran tapete de bienvenida DoS?
Lo que probé antes pareció funcionar, pero en realidad no lo hizo; si te importa, debes revisar el historial de edición de la wiki ...
Lo que hace el trabajo (para mí) es, a la vez disminuir el valor de retardo pam_faildelay.so = X en /etc/pam.d/login (Bajé a 500.000, la mitad de un segundo), y también añadir nodelay (precedido por una space) hasta el final de la línea en common-auth , como lo describe Gabriel en su respuesta.
auth [success=1 default=ignore] pam_unix.so nullok_secure nodelay
Al menos para mí (debian sid), solo hacer uno de estos cambios no acortará la demora apreciablemente por debajo de los 3 segundos predeterminados, aunque es posible alargar la demora cambiando solo el valor en /etc/pam.d/login.
¡Este tipo de mierda es suficiente para hacer llorar a un hombre adulto!
En Ubuntu 9.10, y creo que las nuevas versiones también, el archivo que está buscando se encuentra en
/etc/pam.d/login
editar la línea:
auth opcional pam_faildelay.so delay = 3000000
cambiando el número 3 por otro que desee.
Tenga en cuenta que para tener una autenticación 'nodelay', CREO que debería editar el archivo
/etc/pam.d/common-auth
también. En la línea:
auth [éxito = 1 predeterminado = ignorar] pam_unix.so nullok_secure
agregue 'nodelay' al final (sin comillas). Pero esta explicación final sobre el 'nodelay' es lo que creo.
Me gustaría agregar una nota desde la perspectiva de los desarrolladores. Aunque esto no sería obvio a simple vista, un desarrollador inteligente saldría de una consulta de coincidencia cuando se encuentre la coincidencia. En testimonio, un partido exitoso se completaría más rápido que un partido fallido. Porque, la función de coincidencia compararía las credenciales con todas las cuentas conocidas hasta que encuentre la coincidencia correcta. En otras palabras, digamos que hay 1.000.000 de cuentas de usuario ordenadas por ID; 001, 002, 003 y así sucesivamente. Su identificación es 43,001. Entonces, cuando ingresa un nombre de usuario y contraseña correctos, el escaneo se detiene en 43,001 y lo conecta. Si sus credenciales son incorrectas, entonces escanea todos los 1,000,000 registros. La diferencia en el tiempo de procesamiento en un servidor de doble núcleo puede ser de milisegundos. En Windows Vista con 5 cuentas de usuario, sería en nanosegundos.
Técnicamente, este retraso deliberado es para prevenir ataques como el "ataque de linealización" (hay otros ataques y razones también) .
Para ilustrar el ataque, considere un programa (sin este retraso deliberado), que verifica una serie introducida para ver si coincide con la serie correcta, que en este caso resulta ser " xyba " . Para mayor eficiencia, el programador decidió verificar un carácter a la vez y salir tan pronto como se encuentre un carácter incorrecto, antes de comenzar, también se verifican las longitudes.
La longitud de serie correcta tardará más en procesarse que una longitud de serie incorrecta. Aún mejor (para el atacante), un número de serie que tiene el primer carácter correcto tomará más tiempo que cualquiera que tenga un primer carácter incorrecto. Los pasos sucesivos en el tiempo de espera se deben a que cada vez que hay un bucle más, se debe realizar una comparación con la entrada correcta.
- Entonces, el atacante puede seleccionar una cadena de cuatro caracteres y que la cadena que comienza con x toma más tiempo. (por conjetura)
- El atacante puede entonces fijar el carácter como x y variar el segundo carácter, en cuyo caso encontrará que y es el que más tarda.
- El atacante puede entonces fijar los dos primeros caracteres como xy y variar el tercer carácter, en cuyo caso encontrará que b el que más tarda.
- El atacante puede entonces fijar los primeros tres caracteres como xyb y variar el cuarto carácter, en cuyo caso encontrarán que a tarda más.
Por lo tanto, los atacantes pueden recuperar la serie un carácter a la vez.
Linearization.docx, salida de muestra
El número de serie tiene cuatro caracteres y cada carácter tiene 128 valores posibles. Entonces hay 128 4 = 2 28 = 268,435,456 posibles seriales . Si el atacante debe adivinar al azar números de serie completos, adivinaría el número de serie en aproximadamente 2 27 = 134,217,728 intentos, lo cual es una enorme cantidad de trabajo . Por otro lado, al usar el ataque de linealización anterior, se requiere un promedio de solo 128/2 = 64 conjeturas para cada letra, para un trabajo total esperado de aproximadamente 4 * 64 = 2 8 = 256 conjeturas, que es una cantidad trivial de trabajo.
Gran parte de las artes marciales escritas están adaptadas de esto (tomado de "Seguridad de la información: principios y práctica" de Mark Stamp). Además, los cálculos anteriores no tienen en cuenta la cantidad de conjeturas necesarias para determinar la longitud de serie correcta.