"must be at least 8 characters long"

"must contain characters at least form 3 of these categories..."

"but only on sundays and if you are less than 40 years old"

"not applicable in the following countries..."


I am not a child - seriously. And this is more of a nuisance than a security gain.

Jeremy Davis's picture

TurnKey is used by thousands of people and because we try to make things "newb friendly" we get a lot of "newbs" with very limited IT experience. I know it may seem crazy that some people may host servers online with admin/root passwords like "password" or "12345" but it has happened...

We primarily implemented the requirements because as TurnKey grew, we started getting a growing volume of support requests from people whose servers had been hacked. Since we implemented "password complexity" requirements, we get a LOT less of them...

It's also worth being aware that many of the third party applications have their own password complexity requirements and/or invalid characters. So removing the requirements from our firstboot scripts in any of those cases would just allow you to set a password which wouldn't allow you to log in...

Ok. So you prefer the "newbs" as users. I get it.

OTOH, there are a lot of "best practices" out there with the non-newbs you do torpedoe with this approach. e.g. it's a pity, that a SHA256 hash is not accepted as a password


I fail to see how that is not complex enough.


Jeremy Davis's picture

I agree that d708a039207009d669e7946dd540fe7cf920c111c9450f57213a45759b4b0ae2 is a safe password and should be accepted as a valid password.

One thought is that we could relax restrictions once a password gets to a certain length? Or another thought is that perhaps we could support an option to set a random password which you could access later? I guess that would only work for stuff other than root Linux user password.

I gave this some more thought and maybe the "right way to go"(tm) would be an OR requirement at some place where you currently have an AND.

I also am in favor of making things secure but at the same time newbie friendly - or userfirendly for that matter (why disadvantage non-newbs right?).

I found this nice site and although it looks legit, i still do not recommend to try it with your "real" passwords.


I tried e.g. Gendarme1970 -> 2000 years, but it warns about "possily a word and a number"

So tried G3ndarme1970 -> also 2000 years without the warning

I think everything > 100 years could be considered secure. Or "secure enough".

Said hash above -> 3 SESVIGINTILLION YEARS ;-)

Playing around more with this reveals that length is more important than character classes, and not using "human friendly groups of characters" a.k.a. words is also relevant.

e.g. a password of "Aasdf1+-" - which is valid by the standards of the current requirements is rated "3 hours" until cracked.

Of course all this time is assuming someone gets ahold of your /etc/shadow or similar. Not some brute-forcing via network, for which Turnkey Linux has the nice fail2ban.

The lowest I was able to achieve for the password tester above with a TKL-compliant password was 1 hour: "Aabcd123"

Contrary to that, a simple "turnk3yl1nux" is estimated 3 years. Not a simple topic.

Then again - why not simply use cracklib-check?


spare the user with character classes and some ad-hoc rules. Simply provide feedback about PW strength and actually LET HIM confirm an allegedly weak password with the remark his machine could be compromised and he'd be to blame.


Jeremy Davis's picture

I really like your thoughts on this and cracklib looks like an awesome tool for the job. It looks like there is also a cracklib python module in Debian (inithooks is written in python). I think that's a great idea! As per your suggestion, we could check against cracklib and provide feedback.

I'm not really in a position to get onto this right now, but it's a fantastic idea, so I've opened a feature request on our tracker to ensure that it doesn't get forgotten.

Add new comment