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

83

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.

security authentication passwords Flávio Amieiro
fuente
Descubrirá que esto también es cierto para Windows. Además, cambiar el título a algo como "¿Por qué las contraseñas incorrectas tardan más que las correctas?". Lo haría más relacionado con la programación.
he_the_great
Acabo de iniciar sesión en mi sistema Ubuntu, ingresé la contraseña incorrecta y me hice la misma pregunta. :-)
johngreen

Respuestas:

106

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.

  • Un par de usuario / contraseña exitoso debería tener éxito de inmediato.
  • No debe haber ninguna diferencia discernible en las razones del fracaso que pueden ser detectados.

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.

paxdiablo
fuente
1
¿Cómo evita esto que una aplicación se bifurque, pruebe una contraseña y, si no devuelve el éxito en un período de tiempo, elimine -9 al niño y vuelva a bifurcar? Sí, eso solo funciona si puede iniciar sesión como un usuario, pero ¿cuándo ha detenido a alguien?
BCS
2
No detiene a nadie, pero todavía tienes que esperar ese "tiempo". Incluso una pequeña demora hace que la verificación de millones de contraseñas sea inútil, y será detectado si lo hace mientras está conectado. ¿Cree que no se registra nada para los inicios de sesión fallidos?
paxdiablo
5
BCS: si ya tiene un inicio de sesión válido con suficientes privilegios para hacer lo que propone, es probable que ya no necesite ataques de fuerza bruta (porque hay otros vectores de ataque disponibles para usted). El retraso es más útil contra atacantes externos.
Erich Kitzmueller
14

Esto hace que se tarde más en adivinar las contraseñas.

RossFabricante
fuente
12

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.

Daniel Brückner
fuente
Y, a menudo, el tiempo de espera en el segundo error es más largo que el tiempo de espera en el primero, lo que también es bueno.
Jonathan Leffler
¿Viste la publicación de noticias sobre las contraseñas más probables? 123456 es muy, muy popular.
Spence
@Spence, de hecho vi esos artículos pero, de memoria, no es tan malo como la gente pensaba, estaban (como los medios de comunicación suelen hacer) exagerando. Las contraseñas se obtuvieron de listas de cuentas comprometidas que se encuentran en línea, lo que significa que es mucho más probable que sean inseguras (porque fueron comprometidas). bien123456 podría representar el 30% (por ejemplo) de las cuentas comprometidas, pero es poco probable que sea tan significativo en todas las cuentas.
paxdiablo
No, esas listas son de piratería de bases de datos de contraseñas y la mayoría de ellas representan conjuntos de muestra por millones. Los resultados de estos ataques se han confirmado en múltiples conjuntos de datos en línea y son altamente representativos del consumidor "promedio". La única forma de obtener mejores contraseñas es aplicarlas en el momento de la creación, o mejor aún, usar la autenticación de 2 factores, que es mucho más útil de todos modos.
Spence
12

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).

user32542
fuente
8

Es una forma muy sencilla y prácticamente sin esfuerzo de aumentar considerablemente la seguridad. Considerar:

  1. 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.

  2. 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. :-)

Adam Liss
fuente
4

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 )

Pierre-Luc Simard
fuente
1

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?


fuente
eso no es lo que querían decir. Existe una diferencia obvia entre obtener una contraseña incorrecta o correcta. lo que querían decir era que no debería haber diferencia entre un nombre de usuario incorrecto y una contraseña incorrecta. y ¿te refieres a ejecutar este ataque en paralelo? ¿cómo se puede ejecutar en paralelo?
mpen
@Mark, ejecutar en paralelo probablemente implicaría abrir múltiples conexiones e intentar iniciar sesión. Aún requiere mucho tiempo y no es muy práctico.
he_the_great
Si puede ejecutar un millón de comprobaciones por segundo en una conexión no ralentizada y la conexión luego tiene un retraso de 1 segundo agregado para los intentos fallidos, necesitaría un millón de clientes de ataque para obtener el mismo efecto. Dudo que el servidor permita que se creen tantas sesiones de telnet.
paxdiablo
el punto es que no tiene que esperar el retraso antes de intentar la siguiente contraseña, entonces, ¿de qué sirve?
@Greg, debe volver a conectarse al host y, si es necesario, el siguiente paso sería verificar las direcciones IP para detectar esto también.
paxdiablo
1

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!

user383869
fuente
0

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.

Gabriel L. Oliveira
fuente
0

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.

user368580
fuente
Creo que el 99% de los carteles aquí son desarrolladores de un nivel u otro. Deja de sonar tan pomposo.
Yo uso Ubuntu y solo hay un usuario. Sin embargo, cuando envío una contraseña incorrecta, me toma 3 segundos obtener una respuesta. Entonces, estás equivocado :)
Halil Bilgin
0

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

Jim
fuente
0

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.java.

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.

Ashesh Kumar Singh
fuente