it-swarm-es.tech

¿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 Sudo con una contraseña incorrecta, también tengo que esperar antes de que 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.

93
phunehehe

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

Ingeniería de seguridad ( 2ed, Amazon | 1ed, gratis ) da una explicación mucho mejor de estos problemas.

94
xenoterracide

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

42
Michael Mrozek

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_DELAY en /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 rastreas las inclusiones a partir de /etc/pam.d/Sudo, descubres que tienes 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, eso mismo system-auth el archivo se incluye por 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 lo pueden evitar 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, todavía puedes detener a Sudo con Ctrl-Z, ya que Sudo no atrapa SIGTSTP, y después de detenerlo puedes 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 volver a sudo.

12
user3188445