No Fedora 19
Quando eu corro, eu fico bem. Eu estou no Fedora 19.
$ echo 'M1uG*xgRCthKWwjIjWc*010iSthY9buc' | cracklib-check
M1uG*xgRCthKWwjIjWc*010iSthY9buc: OK
Estas são as informações da versão:
$ rpm -qfi /usr/sbin/cracklib-check | grep -E "Version|Release"
Version : 2.8.22
Release : 3.fc19
OBSERVAÇÃO: Eu tentaria com aspas simples em vez de duplas também, já que você está lidando com *
, elas podem estar sendo expandidas de formas estranhas para você.
CentOS 5 & 6
Tentar o seu exemplo no CentOS 6 foi bom, conseguiu um OK, mas falhou como você descreveu no CentOS 5.9.
$ echo 'M1uG*xgRCthKWwjIjWc*010iSthY9buc' | cracklib-check
M1uG*xgRCthKWwjIjWc*010iSthY9buc: it is too simplistic/systematic
Informação da versão:
$ rpm -qfi /usr/sbin/cracklib-check | grep -E "Version|Release"
Version : 2.8.9
Release : 3.3
Um bug?
O que você encontrou parece ser um bug. Se você pegar sua string e executar mais e mais a sua string em cracklib-check
, perceberá que quando chegar ao 26º caractere, ele começará a falhar:
# 25
$ cracklib-check <<<"M1uG*xgRCthKWwjIjWc*010iS"
M1uG*xgRCthKWwjIjWc*010iS: OK
# 26
$ cracklib-check <<<"M1uG*xgRCthKWwjIjWc*010iSt"
M1uG*xgRCthKWwjIjWc*010iSt: it is too simplistic/systematic
Indo mais fundo nisso, se eu alterar o último caractere de um t
para dizer v
, ele continuará funcionando.
$ cracklib-check <<<"M1uG*xgRCthKWwjIjWc*010iSvhY9b"
M1uG*xgRCthKWwjIjWc*010iSvhY9b: OK
Assim, parece que na versão de cracklib-check
está ficando suspenso na substring Sth
.
Definitivamente, há algo de estranho nos trechos da string que você forneceu. Se eu pegar a parte final da cauda e omitir a parte da frente, posso fazer com que essa parte também falhe.
$ cracklib-check <<<"jIjc*010Sth"
jIjc*010Sth: it is too simplistic/systematic
Essa mesma string causa problemas no Fedora 19 & CentOS 6 também!
UPDATE # 1
Com base em @ investigação muito agradável sobre o waxwing, agora sabemos que a heurística usada estava se desequilibrando se & gt ; 4 caracteres eram muito adjacentes um ao outro. Um patch foi introduzido , que alterou esta heurística, de modo que o comprimento total da senha sob consideração foi levado em conta para elimine esses falsos positivos.
Conclusões?
Com base em alguns dos meus testes limitados, parece que existem algumas heurísticas estranhas em jogo aqui. Certas cordas que aparentemente ficariam bem estão tropeçando.
Se você está tentando codificar isso, eu sugiro envolver a geração & avaliação de uma senha e, em seguida, quebra do loop uma vez gerada uma senha que agrada cracklib-check
.
Ou, pelo menos, sugiro atualizar para uma versão mais recente que inclua as correções que @maxwing menciona em sua resposta.
Alternativas Gen de Senha
pwgen
Eu também vou adicionar que eu costumo usar pwgen
para gerar senhas. Isso pode ser útil para você também aqui.
$ pwgen -1cny 32
iWu0iPh8aena9raSoh{v6me)eh:eu6Ei
urandom
Você também pode usar um pouco de mágica de script com tr
, /dev/urandom
e fold
para obter uma senha aleatória de qualidade extremamente alta.
$ tr -dc '[:graph:]' </dev/urandom | fold -w 32 | head -n 1
;>$7\'Hl$=zn}R.b3h/uf7mY54xp}zSF
O comando fold
pode controlar o comprimento. Como alternativa, você também pode fazer isso:
$ echo $(tr -dc '[:graph:]' </dev/urandom | head -c 32)
/_U>s[#_eLKAl(mrE@oo%X~/pcg$6-kr