Pourquoi la vérification d'un mot de passe incorrect prend-elle plus de temps que celle du bon?
Cette question m'a toujours troublé.
Sous Linux, lorsqu'on vous demande un mot de passe, si votre saisie est la bonne, elle vérifie immédiatement et presque sans délai. Par contre, si vous tapez un mot de passe incorrect, la vérification prend plus de temps. Pourquoi donc?
J'ai observé cela dans toutes les distributions Linux j'ai déjà essayé.
Il s'agit en fait d'empêcher les attaques par force brute d'essayer des millions de mots de passe par seconde. L'idée est de limiter la rapidité avec laquelle les mots de passe peuvent être vérifiés et un certain nombre de règles doivent être suivies.
- Une paire utilisateur/mot de passe réussie doit réussir immédiatement.
- Il devrait y avoir pas / différence perceptible dans les raisons de l'échec qui peuvent être détectées.
Ce dernier est particulièrement important. Cela ne signifie aucun message utile comme:
Your user name is correct but your password is wrong, please try again
ou:
Sorry, password wasn't long enough
Pas même une différence de temps en réponse entre les raisons d'échec "utilisateur et mot de passe non valides" et "utilisateur valide mais mot de passe non valide".
Chaque échec doit fournir exactement les mêmes informations, textuelles ou autres.
Certains systèmes vont encore plus loin en augmentant le délai à chaque échec ou en n'autorisant que trois échecs, ce qui entraîne un délai énorme avant d'autoriser une nouvelle tentative.
Cela prend plus de temps pour deviner les mots de passe.
Je ne suis pas sûr, mais il est assez courant d'intégrer un délai après la saisie d'un mot de passe erroné pour rendre les attaques plus difficiles. Cela rend une attaque pratiquement impossible, car il ne vous faudra que peu de temps pour vérifier quelques mots de passe.
Même en essayant quelques mots de passe - dates de naissance, nom du chat, et des choses comme ça - ne s’amuse pas.
Fondamentalement, limiter les attaques par force brute et par dictionnaire.
De Le Guide du développeur d'applications Linux-PAM :
Planification des retards
extern int pam_fail_delay(pam_handle_t *pamh, unsigned int micro_sec);Cette fonction est proposée par Linux-PAM pour faciliter les retards après un appel ayant échoué à pam_authenticate () et avant le retour du contrôle à l’application. Lors de l'utilisation de cette fonction, le programmeur d'application doit vérifier si elle est disponible avec,
#ifdef PAM_FAIL_DELAY .... #endif /* PAM_FAIL_DELAY */Généralement, une application demande à un utilisateur de s'authentifier par Linux-PAM via un appel à pam_authenticate () ou pam_chauthtok (). Ces fonctions appellent chacun des modules d’authentification empilés répertoriés dans le fichier de configuration Linux-PAM correspondant. Conformément aux instructions de ce fichier, un ou plusieurs des modules peuvent échouer et l’appel pam _... () renvoie une erreur. Il est souhaitable qu'il y ait également une pause avant que l'application ne continue. La raison principale de ce retard est la sécurité: un retard décourage principalement les attaques par le dictionnaire de la force brute, mais contribue également à empêcher les attaques programmées (canal caché).
C'est un moyen très simple et pratiquement sans effort d'accroître considérablement la sécurité. Considérer:
Le système
An'a pas de délai. Un attaquant a un programme qui crée des combinaisons nom d'utilisateur/mot de passe. À des milliers de tentatives par minute, il ne faut que quelques heures pour essayer chaque combinaison et enregistrer toutes les connexions réussies.System
Bgénère un délai de 5 secondes après chaque estimation incorrecte. L'efficacité de l'attaquant a été réduite à 12 tentatives par minute, paralysant efficacement l'attaque par la force brute. Au lieu de plusieurs heures, il peut prendre des mois pour trouver un identifiant valide. Si les pirates informatiques étaient ce patient, ils seraient légitimes. :-)
Les retards d’authentification ont pour but de réduire le taux de tentatives de connexion. L'idée que si quelqu'un essaie un dictionnaire ou une attaque en force brute contre un ou plusieurs comptes d'utilisateurs, l'attaquant devra attendre le délai d'échec, le forçant ainsi à prendre plus de temps et à vous donner plus de chances de le détecter.
Vous voudrez peut-être aussi savoir que, selon ce que vous utilisez comme shell de connexion, il existe généralement un moyen de configurer ce délai.
Dans GDM, le délai est défini dans le fichier gdm.conf (généralement dans /etc/gdm/gdm.conf). vous devez définir RetryDelay = x où x est une valeur en secondes.
La plupart des distributions Linux de ce jour supportent également la définition de FAIL_DELAY dans /etc/login.defs, ce qui vous permet de définir un délai d’attente après une tentative de connexion infructueuse.
Enfin, PAM vous permet également de définir un attribut nodelay sur votre ligne d'authentification pour contourner le délai d'échec. ( Voici un article sur PAM et Linux )
Je ne vois pas que cela puisse être aussi simple que le suggèrent les réponses.
Si la réponse à un mot de passe correct est (une valeur de) immédiate, ne devez-vous pas attendre plus longtemps que cette valeur pour savoir que le mot de passe est erroné? (au moins, savoir de façon probabiliste, ce qui convient pour le cracking) Et de toute façon, vous lanceriez cette attaque en parallèle ... s'agit-il d'un gros tapis de bienvenue pour le DoS?
Ce que j’avais essayé auparavant semblait fonctionner, mais ne l’a pas fait; si vous vous en souciez, vous devez consulter l'historique d'édition du wiki ...
What does work (pour moi) est, to both diminue la valeur de pam_faildelay.so delay = X dans /etc/pam.d/login (je l’ai abaissée à 500000, la moitié une seconde), et aussi add nodelay (précédé d'un espace) à la fin de la ligne dans common-auth , comme décrit par Gabriel dans sa réponse.
auth [success=1 default=ignore] pam_unix.so nullok_secure nodelay
Du moins pour moi (debian sid), le seul fait d’apporter une de ces modifications ne raccourcira pas sensiblement le délai sous les 3 secondes par défaut, bien qu’il soit possible de le prolonger en modifiant uniquement la valeur dans /etc/pam.d/login.
Ce genre de merde suffit à faire pleurer un adulte!
Techniquement, ce délai délibéré consiste à empêcher des attaques telles que le "attaque de linéarisation" (il existe également d'autres attaques et raisons)}.
Pour illustrer l'attaque, considérons un programme (sans ce délai délibéré), qui vérifie le numéro de série entré pour voir s'il correspond au numéro de série correct, qui dans ce cas est "xyba _" . Par souci d'efficacité, le programmeur a décidé de vérifier un caractère à la fois et de quitter dès qu'un caractère incorrect est trouvé, avant de commencer, les longueurs sont également vérifiées.
La longueur de série correcte prendra plus de temps à traiter qu'une longueur de série incorrecte. Encore mieux (pour l’attaquant), un numéro de série dont le premier caractère est correct prendra plus de temps que celui dont le premier caractère est incorrect. Les étapes successives du temps d’attente sont dues au fait que chaque fois qu’il y a une boucle de plus, la comparaison passe par une entrée correcte.
- Ainsi, l’attaquant peut sélectionner une chaîne de quatre caractères et que la chaîne commençant par x prenne le plus de temps. (par deviner le travail)} _
- L'attaquant peut alors fixer le caractère sous la forme x et modifier le deuxième caractère. Dans ce cas, il s'aperçoit que y est le plus long.
- L'attaquant peut alors fixer les deux premiers caractères comme xy et modifier le troisième caractère. Dans ce cas, ils constateront que b prend le plus de temps.
- L'attaquant peut alors fixer les trois premiers caractères comme xyb et modifier le quatrième, auquel cas ils constateront que a prend le plus de temps.
Ainsi, les attaquants peuvent récupérer le caractère en série un à la fois.
Linéarisation.docx, exemple de sortie
Le numéro de série est composé de quatre caractères et chaque caractère a 128 valeurs possibles. Ensuite, il y a 1284 = 228 = 268,435,456 publications en série possibles . Si l'attaquant doit deviner au hasard des numéros de série complets, il devine le numéro de série dans environ 227 = 134 217 728 essais, ce qui représente une énorme quantité de travail . D'autre part, en utilisant l'attaque de linéarisation ci-dessus, une moyenne de seulement 128/2 = 64 suppositions est requise pour chaque lettre, pour un total travail attendu d'environ 4 * 64 = 28 = 256 suppositions, , ce qui est une somme de travail triviale.
Une grande partie de la martiale écrite est adaptée de this (extraite de "Sécurité de l'information: principes et pratiques" de Mark Stamp). De plus, les calculs ci-dessus ne tiennent pas compte de la quantité de conjectures nécessaire pour déterminer la longueur de série correcte.
Sur Ubuntu 9.10, et les nouvelles versions aussi, le fichier que vous recherchez se trouve sur
/etc/pam.d/login
éditer la ligne:
auth optionnel pam_faildelay.so delay = 3000000
changer le numéro 3 avec un autre que vous voudrez peut-être.
Notez que pour avoir une authentification "nodelay", je pense que vous devriez éditer le fichier
/etc/pam.d/common-auth
aussi. Sur la ligne:
auth [success = 1 default = ignore] pam_unix.so nullok_secure
ajoutez 'nodelay' à la finale (sans les guillemets). Mais je pense que cette explication finale à propos du "délai" est ce que je pense.
Je suis d'accord. Ceci est une décision de programmation arbitraire. Le fait de fixer le délai à une seconde au lieu de trois ne nuit pas vraiment à la déchirure du mot de passe, mais le rend plus convivial.
J'aimerais ajouter une note du point de vue des développeurs. Bien que cela ne soit pas évident à l'œil nu, un développeur intelligent se démarquerait d'une requête de correspondance lorsque celle-ci serait trouvée. En témoignage, une correspondance réussie se terminerait plus rapidement qu'une correspondance ratée. En effet, la fonction de correspondance comparera les informations d'identification à tous les comptes connus jusqu'à ce qu'elle trouve la correspondance correcte. En d'autres termes, supposons qu'il y ait 1 000 000 comptes d'utilisateurs classés par ID; 001, 002, 003 et ainsi de suite. Votre identifiant est 43,001. Ainsi, lorsque vous entrez un nom d'utilisateur et un mot de passe corrects, l'analyse s'interrompt à 43 001 et vous enregistre. Si vos informations d'identification sont incorrectes, il analyse tous les 1 000 000 enregistrements. La différence de temps de traitement sur un serveur double cœur peut être de l'ordre de la milliseconde. Sous Windows Vista avec 5 comptes d'utilisateur, ce serait en nanosecondes.