No Fedora 19
Quando eu corro, eu fico bem. Estou no Fedora 19.
$ echo 'M1uG*xgRCthKWwjIjWc*010iSthY9buc' | cracklib-check
M1uG*xgRCthKWwjIjWc*010iSthY9buc: OK
Aqui estão as informações da versão:
$ rpm -qfi /usr/sbin/cracklib-check | grep -E "Version|Release"
Version : 2.8.22
Release : 3.fc19
NOTA: Eu tentaria com aspas simples, em vez de aspas duplas, já que você está lidando com *
elas. Elas podem estar sendo expandidas de maneiras estranhas para você.
CentOS 5 e 6
Tentar o seu exemplo no CentOS 6 foi bom, tudo bem, 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 inseto?
O que você encontrou parece um bug. Se você pegar sua string e executar cada vez mais, cracklib-check
verá que, quando chegar ao 26º caractere, começa 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
Aprofundando isso se eu mudar o último caractere de a t
para dizer v
que continua funcionando.
$ cracklib-check <<<"M1uG*xgRCthKWwjIjWc*010iSvhY9b"
M1uG*xgRCthKWwjIjWc*010iSvhY9b: OK
Então, parece que na versão cracklib-check
está ficando pendurado na substring Sth
.
Definitivamente, há algo estranho nos pedaços da corda que você forneceu. Se eu pegar a parte final da cauda e omitir a parte frontal, também posso fazer com que essa parte falhe.
$ cracklib-check <<<"jIjc*010Sth"
jIjc*010Sth: it is too simplistic/systematic
Essa mesma string também causa problemas no Fedora 19 e no CentOS 6!
ATUALIZAÇÃO # 1
Com base no excelente detalhamento do @ waxwing , agora sabemos que a heurística usada estava sendo disparada se> 4 caracteres estivessem muito próximos um do outro. Foi introduzido um patch que alterava essa heurística para que o comprimento total da senha em consideração fosse levado em consideração para eliminar esses falsos positivos.
Conclusões?
Com base em alguns dos meus testes limitados, parece que existem algumas heurísticas estranhas em jogo aqui. Certas seqüências de caracteres que aparentemente seriam boas estão tropeçando.
Se você estiver tentando codificar isso, sugiro agrupar a geração e a avaliação de uma senha e interromper o ciclo assim que uma senha for gerada e apaziguar cracklib-check
.
Ou, pelo menos, sugiro atualizar para uma versão mais recente que inclua as correções mencionadas pelo @maxwing em sua resposta.
Alternativas de geração de senha
pwgen
Também acrescentarei que costumo usar pwgen
para gerar senhas. Isso pode ser útil para você aqui também.
$ pwgen -1cny 32
iWu0iPh8aena9raSoh{v6me)eh:eu6Ei
urandom
Você também pode usar um pouco de magia scripting com tr
, /dev/urandom
e fold
para obter uma senha aleatória de altíssima qualidade.
$ tr -dc '[:graph:]' </dev/urandom | fold -w 32 | head -n 1
;>$7\`Hl$=zn}R.b3h/uf7mY54xp}zSF
O fold
comando 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
M1uG*xgRCthKWwjIjWc*010iSthY9buc: OK