Pourquoi ce mot de passe aléatoire est-il signalé comme trop simpliste / systématique?

37

Comment la chaîne aléatoire M1uG*xgRCthKWwjIjWc*010iSthY9bucdétectée est-elle trop simpliste / systématique pour un mot de passe selon passwd et cracklib-check ? Essayez-le sur votre machine et voyez

echo "M1uG*xgRCthKWwjIjWc*010iSthY9buc" | cracklib-check

Notez que ce n'est pas mon mot de passe, mais une autre chaîne générée de manière aléatoire à partir du même générateur de mot de passe aléatoire qui produit le même résultat.

BeowulfNode42
la source
3
C'est écritM1uG*xgRCthKWwjIjWc*010iSthY9buc: OK
rici
Il s'avère que seules certaines versions détectent cela comme simple. Voir la réponse de slm pour plus d'informations à ce sujet.
BeowulfNode42
Pourquoi ne pas utiliser plutôt /dev/urandompour générer un mot de passe?
devnull
@devnull - je ne sais pas trop ce que vous aviez à l'esprit, mais j'ai ajouté 2 méthodes à mon A pour générer des mots de passe.
slm

Réponses:

59

Puisque cracklib est open source, la réponse peut être trouvée dans le code source .

"Trop simpliste / systématique" signifie qu'il y a trop de caractères précédés de l'un de leurs voisins alphabétiques. Par conséquent, "ab" ou "ba" sont considérés comme mauvais, mais "ac" ou "ca" sont acceptables car le b est omis.

Avant cette mise à jour du 02/03/2010 , il autorise au maximum quatre personnages présentant ce trait. Par exemple, "bar12345" échouerait, car les caractères "a", "2", "3", "4" et "5" sont des voisins alphabétiques des caractères précédents.

slm a découvert dans sa réponse que M1uG*xgRCthKWwjIjWc*010iSc’était bien, mais M1uG*xgRCthKWwjIjWc*010iStne l’est pas. Analysons. Voici les caractères qui, selon cracklib-check, indiquent un mot de passe systématique:

M1uG*xgRCthKWwjIjWc*010iS
               ^^    ^^

qui est inférieur au maximum de quatre, mais en ajoutant le t:

M1uG*xgRCthKWwjIjWc*010iSt
               ^^    ^^  ^

le pousse au-dessus de la limite, puisque T suit S (il semble que le test ne respecte pas la casse).

Le patch modifie la limite maximale, elle dépend donc de la longueur totale du mot de passe, afin d'éviter de tels faux positifs.

jaseur
la source
1
010 ne devrait-il pas compter déjà comme 3? Bonne réponse cependant.
John V.
1
Excellente réponse et merci d'avoir fourni le diff de code source exact. À propos, y a-t-il une raison pour laquelle ce fichier s'appelle fascist.c?
laurent
@ this.lau_ - J'imagine: en.wikipedia.org/wiki/Fascisme
slm
Un peu drôle de parler de "plus petit" et de "plus grand" en ce qui concerne les personnages, non? Bien que je sache qu’il s’agit de valeurs ASCII, cela n’est peut-être pas trop évident. - Alors pourquoi ne pas l'expliquer de manière plus simpliste? Aucun caractère ne doit être suivi de son voisin direct ni de son prédécesseur. Par conséquent, ni "ab" ni "ba" ne sont autorisés, mais "ac" ou "ca" le serait puisque le b est omis.
syntaxerror
Y a-t-il une raison pour laquelle il ne peut pas être plus petit ou plus élevé, mais peut être identique ( Ww)?
Jeroen Vannevel
31

Sur Fedora 19

Quand je le lance, tout va bien. Je suis sur Fedora 19.

$ echo 'M1uG*xgRCthKWwjIjWc*010iSthY9buc' | cracklib-check
M1uG*xgRCthKWwjIjWc*010iSthY9buc: OK

Voici les informations de version:

$ rpm -qfi /usr/sbin/cracklib-check | grep -E "Version|Release"
Version     : 2.8.22
Release     : 3.fc19

NOTE: J'essaierais de le faire avec des guillemets simples au lieu de doubles questions car vous avez affaire à des problèmes qui *pourraient se développer de façon étrange.

CentOS 5 et 6

Essayer votre exemple sur CentOS 6 était très bien, vous avez obtenu un OK, mais cela a échoué comme vous l’avez décrit dans CentOS 5.9.

$ echo 'M1uG*xgRCthKWwjIjWc*010iSthY9buc' | cracklib-check
M1uG*xgRCthKWwjIjWc*010iSthY9buc: it is too simplistic/systematic

Informations de version:

$ rpm -qfi /usr/sbin/cracklib-check | grep -E "Version|Release"
Version     : 2.8.9                  
Release     : 3.3

Un bug?

Ce que vous avez découvert semble être un bug. Si vous prenez votre chaîne et la lancez de plus en plus, cracklib-checkvous remarquerez que lorsque vous arrivez au 26ème caractère, cela commence à échouer:

# 25    
$ cracklib-check <<<"M1uG*xgRCthKWwjIjWc*010iS"
M1uG*xgRCthKWwjIjWc*010iS: OK

# 26
$ cracklib-check <<<"M1uG*xgRCthKWwjIjWc*010iSt"
M1uG*xgRCthKWwjIjWc*010iSt: it is too simplistic/systematic

Creuser plus profondément là-dessus si je change le dernier caractère d'un tpour dire vqu'il continue de fonctionner.

$ cracklib-check <<<"M1uG*xgRCthKWwjIjWc*010iSvhY9b"
M1uG*xgRCthKWwjIjWc*010iSvhY9b: OK

Donc, il semblerait que dans la version de cracklib-checkse raccroche à la sous-chaîne Sth.

Il y a certainement quelque chose d'étrange dans les morceaux de la ficelle que vous avez fournie. Si je prends la queue et omet la partie avant, je peux également faire échouer cette partie.

$ cracklib-check <<<"jIjc*010Sth"
jIjc*010Sth: it is too simplistic/systematic

Cette même chaîne cause également des problèmes sur Fedora 19 & CentOS 6!

MISE À JOUR # 1

Basé sur la très belle recherche de @ waxwing , nous savons maintenant que l'heuristique utilisée a été déclenchée si> 4 caractères étaient trop adjacents les uns aux autres. Un correctif a été introduit pour modifier cette heuristique afin que la longueur totale du mot de passe considéré soit prise en compte pour éliminer ces faux positifs.

Des conclusions?

Sur la base de certains de mes tests limités, il semblerait que des heuristiques étranges soient en jeu ici. Certaines ficelles qui sembleraient aller bien le font trébucher.

Si vous essayez de codifier cela, je vous conseillerais de terminer la génération et l'évaluation d'un mot de passe, puis de sortir de la boucle une fois qu'un mot de passe généré aura apaisé cracklib-check.

Ou à tout le moins, je suggérerais de passer à une version plus récente incluant les correctifs mentionnés par @maxwing dans sa réponse.

Mot de passe alternatif

pwgen

J'ajouterai également que j'utilise généralement pwgenpour générer des mots de passe. Cela pourrait vous être utile ici aussi.

$ pwgen -1cny 32
iWu0iPh8aena9raSoh{v6me)eh:eu6Ei
urande

Vous pouvez également utiliser un peu de magie de script avec tr, /dev/urandomet foldd'obtenir un mot de passe aléatoire de très haute qualité.

$ tr -dc '[:graph:]' </dev/urandom | fold -w 32 | head -n 1
;>$7\`Hl$=zn}R.b3h/uf7mY54xp}zSF

La foldcommande peut contrôler la longueur. Comme alternative, vous pouvez aussi le faire:

$ echo $(tr -dc '[:graph:]' </dev/urandom | head -c 32)
/_U>s[#_eLKAl(mrE@oo%X~/pcg$6-kr
slm
la source
Je courais sur CentOS 5.5 avec cracklib-2.8.9-3.1.src.rpm. Dans les deux cas, comment une chaîne aussi longue et aléatoire peut-elle être trop simple?
BeowulfNode42
@ BeowulfNode42 - ce n'est pas. On dirait que vous avez trouvé un bogue, ou à tout le moins une limitation de la mise en œuvre.
slm
Étrange. Pourtant, une chaîne comme Tm7U:n=@*+4$*gf$6hOngEHJ;mnh$+R6est parfaitement OK sur la même machine.
BeowulfNode42
1
Les guillemets doubles font empêcher l' expansion de glob. Les guillemets simples sont toujours une meilleure idée cependant, au cas où la chaîne contiendrait des signes dollar, des backticks, etc.
Dennis
2
"Un patch a été introduit ..." Il convient également de noter que le patch en question n'est en aucun cas récent (contrairement à ce que cela peut paraître), mais qu'il a déjà été envoyé en 2010 :)
syntaxerror