¿Por qué debería tardar más comprobar una contraseña incorrecta que comprobar la correcta?

Esto hace que tome más tiempo adivinar contraseñas.

No estoy seguro, pero es bastante común integrar un retraso después de introducir una contraseña incorrecta para hacer los ataques más difíciles. Esto hace que un ataque sea prácticamente inviable, ya que 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 es divertido.

Básicamente para mitigar contra la fuerza bruta y los ataques del diccionario.

De La Guía para Desarrolladores de Aplicaciones Linux-PAM :

Planificación de retrasos

extern int pam_fail_delay(pam_handle_t *pamh, unsigned int micro_sec);

Esta función es ofrecida por Linux-PAM para facilitar los retrasos después de una llamada fallida a pam_authenticate () y antes de que se devuelva el control al aplicación. Cuando se utiliza esta función el programador de aplicaciones debe compruebe si está disponible con,

#ifdef PAM_FAIL_DELAY
    ....
#endif /* PAM_FAIL_DELAY */

Generalmente, una solicitud solicita que un usuario es autenticado por Linux-PAM a través de una llamada a pam_authenticate() o pam_chauthtok(). Estas funciones llaman a cada uno de los lista de módulos de autenticación apilados en el Linux-PAM correspondiente archivo de configuración. Según lo dirigido por este archivo, uno de más de los módulos puede fallar causando el pam_...() llamar a devuelve un error. Es deseable para también habrá una pausa antes de la la solicitud continúa. Principal motivo tal retraso es la seguridad: un el retraso actúa para desalentar la fuerza bruta el diccionario ataca principalmente, pero también ayuda a obstaculizar timed (canal encubierto) ataques.

Es una manera muy simple, prácticamente sin esfuerzo para aumentar en gran medida la seguridad. Considere:

1. El sistema A no tiene retraso. Un atacante tiene un programa que crea combinaciones de nombre de usuario / contraseña. A un ritmo de miles de intentos por minuto, solo toma unas pocas horas probar cada combinación y registrar todos los inicios de sesión exitosos.

2. System B genera un retraso de 5 segundos después de cada suposición incorrecta. La eficiencia del atacante se ha reducido a 12 intentos por minuto, efectivamente paralizando el ataque de fuerza bruta. En lugar de horas, puede tomar meses encontrar un inicio de sesión válido. Si los hackers fueran ese paciente, 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, ese atacante tendrá que esperar el retraso de falla y, por lo tanto, lo obligará a tomarse más tiempo y le dará más posibilidades de detectarlo.

También podría interesarle saber que, dependiendo de lo que esté utilizando como shell de inicio de sesión, generalmente hay una forma de configurar este retraso.

En GDM, el retardo se establece en el gdm.archivo conf (normalmente en/etc/gdm / gdm.conf). es necesario establecer RetryDelay = x donde x es un valor en segundos.

La mayoría de las distribuciones de linux actualmente también soportan tener FAIL_DELAY definido en /etc/login.defs que le permite establecer un tiempo de espera después de un intento de inicio de sesión fallido.

Finalmente, PAM también le permite establecer un atributo nodelay en su línea de autenticación para omitir el retraso de error. (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 más de ese valor para saber que la contraseña es incorrecta? (al menos saber probabilísticamente, que está bien para propósitos de craqueo) Y de todos modos estaría ejecutando este ataque en paralelo... ¿todo esto es una alfombra de bienvenida?

Lo que probé antes parecía funcionar, pero en realidad no lo hizo; si te importa debes revisar el historial de edición del wiki...

Lo que hace trabajo (para mí) es, para ambos bajar el valor de pam_faildelay.so delay = X in /etc/pam.d / login (lo bajé a 500000, medio segundo), y también agregar nodelay (precedido por un espacio) al final de la línea en common-auth , como lo describió Gabriel en su respuesta.

auth [success=1 default=ignore] pam_unix.so nullok_secure nodelay

Al menos para mí (debian sid), solo haciendo uno de estos cambios no acortará el retardo apreciablemente por debajo de los 3 segundos predeterminados, aunque es posible alargar el retardo solo cambiando el valor en /etc/pam.d inicio de sesión.

Este tipo de mierda es suficiente para hacer llorar a un hombre adulto!

En Ubuntu 9.10, y creo que nuevas versiones también, el archivo que estás 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 debe editar el archivo

/etc/pam.d / common-auth

También. En la línea:

Auth [success = 1 default = ignore] pam_unix.so nullok_secure

Agregue 'nodelay' a la final (sin comillas). Pero esta explicación final sobre el' nodelay ' es lo que pienso.

Me gustaría añadir 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 encuentra la coincidencia. En witness, una partida exitosa se completaría más rápido que una partida fallida. 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 cuentas de usuario en orden por IDs; 001, 002, 003 y así sucesivamente. Su identificación es 43,001. Por lo tanto, cuando introduce un nombre de usuario y contraseña correctos, el escaneo se detiene en 43,001 y lo inicia. Si sus credenciales son incorrectas, 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.

Estoy de acuerdo. Esta es una decisión de programación arbitraria. Poner el retraso a un segundo en lugar de tres realmente no daña la posibilidad de descifrar la contraseña, pero la hace más fácil de usar.

Técnicamente, este retraso deliberado {[2] } 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 esto retraso deliberado), que comprueba una serie introducida para ver si coincide con la serie correcta, que en este caso pasa a ser " xyba". Para la eficacia, el programador decidió comprobar uno carácter a la vez y a salir tan pronto como un carácter incorrecto es encontrado, antes de comenzar las longitudes también se comprueban.

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 tiene un primer carácter incorrecto. Los pasos sucesivos en el tiempo de espera es porque cada vez que hay un bucle más, comparación para ir a través de en la entrada correcta.

• Entonces, el atacante puede seleccionar una cadena de cuatro caracteres y que la cadena que comienza con x tome la mayor parte del tiempo. (por conjetura)
• El atacante puede entonces fijar el carácter como xy variar el segundo carácter, en cuyo caso encontrarán que y toma el más largo.
• El atacante puede entonces fijar los dos primeros caracteres como xy y variar el tercer carácter, en cuyo caso encontrarán que b toma el larga.
• El atacante puede entonces fijar los tres primeros caracteres como xyb y variar el cuarto carácter, en cuyo caso encontrarán que a toma el larga.

Por lo tanto, los atacantes pueden recuperar el serial de un personaje a la vez.

Linealización.Java.

Linealización.docx, salida de muestra

El número de serie es de cuatro caracteres y cada carácter tiene 128 valores posibles. , Entonces hay 128⁴ = 2²⁸ = 268,435,456 posibles seriales . Si el atacante debe adivinar al azar números de serie completos, ella adivinaría el número de serie en alrededor de 2²⁷ = 134,217,728 tries, que es una enorme cantidad de trabajo . Por otro lado, utilizando el ataque de linealización anterior, un promedio de solo 128/2 = 64 conjeturas se requieren para cada letra, para un total trabajo esperado de aproximadamente 4 * 64 = 2⁸ = 256 conjeturas, lo cual es una cantidad trivial de trabajo.

Gran parte del marcial escrito está adaptado de this (tomado de Mark Stamp's "Information Security: Principles and Practice"). Además, los cálculos anteriores no tienen en cuenta la cantidad de conjeturas necesarias para averiguar la longitud de serie correcta.