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.

  • 3
    It says M1uG*xgRCthKWwjIjWc*010iSthY9buc: OK
    – rici
    Mar 24, 2014 at 2:29
  • Turns out only some versions detect this as simple. See slm's answer for more info on this. Mar 24, 2014 at 2:47
  • Why don't you instead use /dev/urandom to generate a password?
    – devnull
    Mar 24, 2014 at 2:56
  • @devnull - not sure what you had in mind but added 2 methods to my A on how to generate passwords.
    – slm
    Mar 24, 2014 at 3:26

2 Answers 2


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:

               ^^    ^^

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

               ^^    ^^  ^

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.

  • 1
    Shouldn't 010 count as 3 already? Great answer though.
    – John V.
    Mar 24, 2014 at 23:30
  • 1
    Great answer and thanks for providing the exact source code diff. By the way, is there any reason why this file is called fascist.c?
    – laurent
    Mar 25, 2014 at 1:39
  • @this.lau_ - I'm guessing: en.wikipedia.org/wiki/Fascism
    – slm
    Mar 25, 2014 at 3:27
  • Somewhat funny to talk about "smaller" and "larger" in respect to characters, no? Well, though I know it's about ASCII values it may not be too obvious. -- So why not explain it a more simplistic way? No character must be followed by its direct neighbor nor predecessor. Hence neither "ab" nor "ba" is permitted, but "ac" or "ca" would since the b is omitted. Mar 25, 2014 at 10:26
  • Is there a reason why it can't be one smaller or higher but it can be the same (Ww)? Mar 25, 2014 at 10:32

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!


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.


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


I'll also add that I usually use pwgen to generate passwords. That might be helpful to you here as well.

$ pwgen -1cny 32

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

The fold command can control the length. As an alternative you can do this too:

$ echo $(tr -dc '[:graph:]' </dev/urandom | head -c 32)
  • I was running it on CentOS 5.5 with cracklib-2.8.9-3.1.src.rpm. In either case though how can such a long random string be too simple? Mar 24, 2014 at 2:46
  • @BeowulfNode42 - it isn't. Looks like you've found a bug, or at the very least a limitation of the implementation.
    – slm
    Mar 24, 2014 at 2:49
  • Strange. Yet a string like Tm7U:n=@*+4$*gf$6hOngEHJ;mnh$+R6 is perfectly OK on the same machine. Mar 24, 2014 at 2:51
  • 1
    Double quotes do prevent glob expansion. Single quotes are still a better idea though, in case the string contains dollar signs, backticks, etc.
    – Dennis
    Mar 24, 2014 at 17:46
  • 2
    "A patch was introduced..." It should also be noted that the patch in question is by no means a recent one (unlike the way it may sound), but was already sent in back in 2010 :) Apr 21, 2014 at 22:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .