¿Por qué hay un gran retraso después de ingresar una contraseña incorrecta?

Noto algo extraño (bueno, según yo) sobre las contraseñas. Por ejemplo, si escribo una contraseña incorrecta durante el inicio de sesión, habrá un retraso de unos segundos antes de que el sistema me lo indique. Cuando intento sudocon una contraseña incorrecta, también tengo que esperar antes de que el shell diga "Lo siento, inténtalo de nuevo".

Me pregunto por qué lleva tanto tiempo "reconocer" una contraseña incorrecta. Esto se ha visto en varias distribuciones que uso (e incluso OSX), por lo que creo que no es una distribución específica.

Esto es una cuestión de seguridad, en realidad no está tardando mucho en darse cuenta. 2 vulnerabilidades que esto resuelve:

1. esto acelera los intentos de inicio de sesión, lo que significa que alguien no puede golpear el sistema tan rápido como puede intentar descifrarlo (¿1 millón de intentos por segundo? No lo sé).

2. Si lo hizo tan pronto como verificó que sus credenciales eran incorrectas, podría usar la cantidad de tiempo que le tomó para invalidar sus credenciales para ayudar a adivinar si parte de sus credenciales eran correctas, reduciendo drásticamente el tiempo de adivinanzas.

Para evitar estas 2 cosas, el sistema solo toma una cierta cantidad de tiempo para hacerlo, creo que puede configurar el tiempo de espera con PAM ( vea la respuesta de Michaels ).

La ingeniería de seguridad ( 2ed, amazon | 1ed, gratuita ) ofrece una explicación mucho mejor de estos problemas.

Esto es intencional, para tratar de limitar la fuerza bruta. Por lo general, puede modificarlo buscando la FAIL_DELAYentrada de configuración /etc/login.defsy cambiando su valor (el mío es 3segundos por defecto), aunque el comentario en ese archivo hace que parezca que PAM aplicará al menos un 2segundo retraso sin importar qué

En los sistemas Linux modernos, la razón es que pam_unix.so impone tal retraso. Como se informó anteriormente, esto se puede configurar hasta dos segundos cambiando FAIL_DELAYen /etc/login.defs. Si desea reducir aún más el retraso, debe dar a pam_unix.so la opción "nodelay". Por ejemplo, en mi sistema, si rastrea las inclusiones a partir de /etc/pam.d/sudo, encontrará que tiene que editar la siguiente línea de /etc/pam.d/system-auth:

auth      required  pam_unix.so     try_first_pass nullok

y cámbialo a esto:

auth      required  pam_unix.so     try_first_pass nullok nodelay

Desafortunadamente, la forma en que mi Linux distro (arch) configura las cosas, ese mismo system-autharchivo se incluye system-remote-login, que es utilizado por sshd.

Si bien es seguro eliminar el retraso en sudo, porque eso está registrado, solo lo usan los usuarios locales y los atacantes locales pueden evitarlo de todos modos, probablemente no desee eliminar este retraso para los inicios de sesión remotos. Por supuesto, puede solucionarlo escribiendo un sudo personalizado que no solo incluya los archivos compartidos de autenticación del sistema.

Personalmente, creo que la demora en sudo (e ignorar SIGINT) es un gran error. Significa que los usuarios que saben que escribieron mal la contraseña no pueden matar el proceso y se frustran. Por supuesto, aún puede detener sudo con Ctrl-Z, ya que sudo no atrapa SIGTSTP, y después de detenerlo puede matarlo con kill -9 (SIGKILL). Es molesto hacerlo. Eso significa que un ataque automatizado podría disparar sudos en pseudo terminales a una velocidad súper alta. Pero la demora frustra a los usuarios legítimos y los alienta a suspender sus shells raíz en lugar de salir de ellos para evitar tener que sudo nuevamente.