37

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.

|improve this question
  • 3
    It says M1uG*xgRCthKWwjIjWc*010iSthY9buc: OK – rici Mar 24 '14 at 2:29
  • Turns out only some versions detect this as simple. See slm's answer for more info on this. – BeowulfNode42 Mar 24 '14 at 2:47
  • Why don't you instead use /dev/urandom to generate a password? – devnull Mar 24 '14 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 '14 at 3:26
59

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.

|improve this answer
  • 1
    Shouldn't 010 count as 3 already? Great answer though. – John V. Mar 24 '14 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 '14 at 1:39
  • @this.lau_ - I'm guessing: en.wikipedia.org/wiki/Fascism – slm♦ Mar 25 '14 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. – syntaxerror Mar 25 '14 at 10:26
  • Is there a reason why it can't be one smaller or higher but it can be the same (Ww)? – Jeroen Vannevel Mar 25 '14 at 10:32
31

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
|improve this answer
  • 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? – BeowulfNode42 Mar 24 '14 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 '14 at 2:49
  • Strange. Yet a string like Tm7U:n=@*+4$*gf$6hOngEHJ;mnh$+R6 is perfectly OK on the same machine. – BeowulfNode42 Mar 24 '14 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 '14 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 :) – syntaxerror Apr 21 '14 at 22:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.