Pourquoi y a-t-il un grand délai après la saisie d'un mot de passe incorrect?

Je remarque une chose étrange (bien, selon moi) à propos des mots de passe. Par exemple, si je tape un mot de passe incorrect lors de la connexion, quelques secondes s’écouleront avant que le système me le dise. Lorsque j'essaie d' sudoutiliser un mot de passe incorrect, je dois également attendre avant que le shell ne dise "Désolé, essayez à nouveau".

Je me demande pourquoi il faut tant de temps pour "reconnaître" un mot de passe incorrect? Cela a été vu sur plusieurs distributions que j'utilise (et même sur OSX), donc je pense que ce n'est pas une chose spécifique à la distribution.

Ceci est une question de sécurité, il ne faut pas tarder pour le réaliser. 2 vulnérabilités que cela résout:

1. cela accélère les tentatives de connexion, ce qui signifie que quelqu'un ne peut pas marteler le système aussi vite qu'il peut essayer de le casser (1 M tentatives par seconde? Je ne sais pas).

2. S'il le faisait dès qu'il a vérifié que vos informations d'identification étaient incorrectes, vous pouvez utiliser le temps qu'il a fallu pour l'invalider afin de vous aider à deviner si une partie de vos informations d'identification était correcte, ce qui réduirait considérablement le temps nécessaire pour deviner.

Pour éviter ces deux problèmes, le système prend juste un certain temps, je pense que vous pouvez configurer le temps d'attente avec PAM ( voir la réponse de Michaels ).

L'ingénierie de la sécurité ( 2ed, amazon | 1ed, gratuit ) donne une bien meilleure explication de ces problèmes.

C'est intentionnel, pour essayer de limiter le forçage brutal. Vous pouvez généralement le modifier en recherchant l' FAIL_DELAYentrée de configuration dans /etc/login.defset en modifiant sa valeur (le mien est 3secondes par défaut), bien que le commentaire dans ce fichier donne l'impression que PAM appliquera au moins un 2second délai, peu importe le type

Sur les systèmes linux modernes, la raison en est que pam_unix.so impose un tel délai. Comme indiqué précédemment, cela peut être configuré jusqu'à deux secondes en changeant FAIL_DELAYen /etc/login.defs. Si vous voulez réduire davantage le délai, vous devez donner à pam_unix.so l'option "nodelay". Par exemple, sur mon système, si vous tracez les inclus à partir de /etc/pam.d/sudo, vous devez modifier la ligne suivante de /etc/pam.d/system-auth:

auth      required  pam_unix.so     try_first_pass nullok

et changez cela en ceci:

auth      required  pam_unix.so     try_first_pass nullok nodelay

Malheureusement, de la même manière que ma distribution Linux (arch) configure les choses, ce même system-authfichier est inclus par system-remote-login, utilisé par sshd.

Bien qu'il soit prudent d'éliminer le délai sur sudo, car il est enregistré, utilisé uniquement par les utilisateurs locaux et contournable par les attaquants locaux de toute façon, vous ne souhaiterez probablement pas éliminer ce délai pour les connexions à distance. Vous pouvez bien sûr résoudre ce problème en écrivant un sudo personnalisé qui n'inclut pas uniquement les fichiers partagés avec l'authentification système.

Personnellement, je pense que le retard sur sudo (et ignorer SIGINT) est une grosse erreur. Cela signifie que les utilisateurs qui savent qu'ils ont mal saisi le mot de passe ne peuvent pas arrêter le processus et sont frustrés. Bien sûr, vous pouvez toujours arrêter sudo avec Ctrl-Z, car sudo ne capture pas SIGTSTP, et après l'avoir arrêté, vous pouvez le tuer avec kill -9 (SIGKILL). C'est juste ennuyant à faire. Cela signifie donc qu'une attaque automatisée pourrait déclencher très rapidement des sudos sur des pseudo-terminaux. Toutefois, ce délai frustrant les utilisateurs légitimes et les encourageant à suspendre leur shell racine au lieu de les quitter pour éviter de devoir à nouveau subir une erreur.