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

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.

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.

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!

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

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

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