Why is this random password flagged saying it is too simplistic/systematic?

Question

How is the random string M1uG*xgRCthKWwjIjWc*010iSthY9buc being detected as too simplistic/systematic for a password according to passwd and cracklib-check? Try it on your machine and see

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

Note that this is not my password, but another randomly generated string from the same random password generator that produces the same result.

Answer 1

Since cracklib is open source, the answer can be found in the source code.

"Too simplistic/systematic" means that there are too many characters that are preceded by one of their alphabetical neighbors. Hence "ab" or "ba" are considered bad, but "ac" or "ca" are OK since the b is omitted.

Before this patch from 2010-03-02, it allows at most four characters that exhibit this trait. E.g., "bar12345" would fail, because the characters "a", "2", "3", "4" and "5" are alphabetical neighbors of the preceding characters.

slm found out in his answer that M1uG*xgRCthKWwjIjWc*010iS was OK, while M1uG*xgRCthKWwjIjWc*010iSt is not. Let's analyze. Here are the characters that cracklib-check thinks are indications of a systematic password:

M1uG*xgRCthKWwjIjWc*010iS
               ^^    ^^

which is below the max of four, but adding the t:

M1uG*xgRCthKWwjIjWc*010iSt
               ^^    ^^  ^

pushes it above the limit, since T follows S (it appears the test is case insensitive).

The patch changes the max limit so it depends on the total password length, to avoid false positives like this.

Answer 2

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