On Fedora 19
When I run it I get OK. I'm on Fedora 19.
$ echo 'M1uG*xgRCthKWwjIjWc*010iSthY9buc' | cracklib-check
M1uG*xgRCthKWwjIjWc*010iSthY9buc: OK
Here's the version info:
$ rpm -qfi /usr/sbin/cracklib-check | grep -E "Version|Release"
Version : 2.8.22
Release : 3.fc19
NOTE: I'd try it with single quotes instead of double qutoes too since you're dealing with *
's they might be getting expanded in strange ways on you.
CentOS 5 & 6
Trying your example on CentOS 6 was fine, got an OK, but it did fail as you described on CentOS 5.9.
$ echo 'M1uG*xgRCthKWwjIjWc*010iSthY9buc' | cracklib-check
M1uG*xgRCthKWwjIjWc*010iSthY9buc: it is too simplistic/systematic
Version info:
$ rpm -qfi /usr/sbin/cracklib-check | grep -E "Version|Release"
Version : 2.8.9
Release : 3.3
A bug?
What you've stumbled into would seem to be a bug. If you take your string and run more and more of your string into cracklib-check
you'll notice that when you get to the 26th character it starts to fail:
# 25
$ cracklib-check <<<"M1uG*xgRCthKWwjIjWc*010iS"
M1uG*xgRCthKWwjIjWc*010iS: OK
# 26
$ cracklib-check <<<"M1uG*xgRCthKWwjIjWc*010iSt"
M1uG*xgRCthKWwjIjWc*010iSt: it is too simplistic/systematic
Digging deeper on this if I change the last character from a t
to say v
it continues to work.
$ cracklib-check <<<"M1uG*xgRCthKWwjIjWc*010iSvhY9b"
M1uG*xgRCthKWwjIjWc*010iSvhY9b: OK
So it would seem that in the version of cracklib-check
is getting hung up on the substring Sth
.
There's definitely something strange about chunks of the string you've provided. If I take the tail end piece and omit the front portion I can get this portion to fail as well.
$ cracklib-check <<<"jIjc*010Sth"
jIjc*010Sth: it is too simplistic/systematic
That same string causes issues on Fedora 19 & CentOS 6 too!
UPDATE #1
Based on @waxwing's very nice sleuthing, we now know that the heuristic used was getting tripped up if > 4 characters were too adjacent to each other. A patch was introduced that changed this heuristic so that the overall length of the password under consideration was taken into account to eliminate these false positives.
Conclusions?
Based on some of my limited testing it would appear that there are some strange heuristics at play here. Certain strings that would seemingly be fine are tripping it up.
If you're trying to codify this I would suggest wrapping the generation & evaluation of a password and then breaking out of the loop once a password has been generated that appeases cracklib-check
.
Or at the very least I'd suggest upgrading to a newer version that includes the fixes that @maxwing mentions in his answer.
Password Gen Alternatives
pwgen
I'll also add that I usually use pwgen
to generate passwords. That might be helpful to you here as well.
$ pwgen -1cny 32
iWu0iPh8aena9raSoh{v6me)eh:eu6Ei
urandom
You can also use a little scripting magic with tr
, /dev/urandom
, and fold
to get a extremely high quality random password.
$ tr -dc '[:graph:]' </dev/urandom | fold -w 32 | head -n 1
;>$7\`Hl$=zn}R.b3h/uf7mY54xp}zSF
The fold
command can control the length. As an alternative you can do this too:
$ echo $(tr -dc '[:graph:]' </dev/urandom | head -c 32)
/_U>s[#_eLKAl(mrE@oo%X~/pcg$6-kr
M1uG*xgRCthKWwjIjWc*010iSthY9buc: OK
/dev/urandom
to generate a password?