I'm trying to find a tool to validate the security of a password and I've come across cracklib or libcrack2 (on Debian), which seems to be used a lot for the task and appears to do exactly what I wanted.

However, it does not really depict the requirements I imagined. For a lot of cases it does seem to have some appropriate checks (e.g. reversed dictionary-based words, too simplistic, ...).

The following explains what I mean:

$ echo "wordpass" | cracklib-check
wordpass: OK

Now, wordpass is not what I imagine to be a secure password.

I do not have a specific password policy I'm following, nor do I have a certain value for the desired entropy of the password. Defining "secure" in terms of passwords is a complex task. Given the password is used for a Linux system using PAM, if an attacker is not able to crack it with rainbow tables or bruteforce it within a week, I'd consider it secure.

How could I simply verify the security of a given password on a Linux system?

EDIT: I've come across a more reasonable another tool, passwdqc:

$ echo "wordpass" | pwqcheck -1
Bad passphrase (not enough different characters or classes for this length)

But, as mentioned by the user @Hector the question is very vague and in this form not really answerable, so I'll vote to close the question. but won't delete it as it may be usable for someone else who's not satisfied by the cracklib approach.

$ echo "MyP@ssw0rd" | pwqcheck -1
  • 1
    I disagree that passwdqc is necessarily better. "different characters or classes" does not indicate more secure. A 300 character string of random choices from 8 characters is notably more secure than "abcd1234!". cracklib is also configurable (for example minclass can be changed to require more classes) if you insist on these arbitrary rules which go against all recent expert recommendations.
    – Hector
    Commented Nov 14, 2017 at 14:20
  • 1
    @Hector It doesn't say "different characters or classes", it says "different characters or classes for this length"
    – Ajedi32
    Commented Nov 14, 2017 at 16:27
  • 1
    @Ajedi32 - yes. But its still arbitrary and knowledge of the rules / usual human response to them makes bruteforcing the vast majority of users no harder. The defualt min lengths per class count for pwqcheck would allow "Password1" & "My Easy Pass" but not a 200 character long string of random lowercase characters.
    – Hector
    Commented Nov 14, 2017 at 16:44
  • Unfortunately this is a little too broad because there are two separate, complex ways to answer: A) checking how easy it is to actually crack a password, which requires a thorough explanation of sophisticated cracking techniques, and B) Checking against simple password policies that produce large improvements in strength like length suggestions, complexity requirements, or blacklisting based on lists of popular passwords. Hopefully these comments point you in the right direction though. Commented Nov 15, 2017 at 21:58
  • In general, NOTHING can tell you "this is secure", since nothing has access to every tool and wordlist in every hacker's toolbox now or in the future; however, any tool at all that tells you "this is weak" should be believed without significant question. Further details are in my answer to Should I reject obviously poor passwords? Commented Jan 10, 2018 at 4:26

2 Answers 2


There is not a simple process that can do this. For example is an obscure English dictionary word more or less secure than "MyP@ssw0rd"?

Enforcing rules that require symbols and numbers leads to users using "password1!" etc. and forcing users to rotate passwords leads to "password1", "password2" etc.

if an attacker is not able to crack it with rainbow tables or bruteforce it within a week

Via what mechanism? Over a network with rate limiting? Do they have access to the stored hashes? You need a lot more context for "a week" to have any relevance. For a brute force are they incrementing byte values or using a dictionary? What dictionary? - all you need is a user reusing an otherwise secure password on a site that is hacked...

I'm trying to find a tool to validate the security of a password

Personally I would suggest a combination of character limit (>= 10 characters) combined with checking the password against lists of known to be leaked passwords. For example Have I Been Pwned maintains a list of several hundred million SHA1 hashes of leaked passwords. If the SHA1 of the user entered password is not in there the chances are it wouldn't easily be brute forced / dictionary attacked.

  • I realise that the very question too vague. I did however, come across a more reasonable tool, which I'll mention in the OP in a second - maybe that's useful for someone. Thank you very much for your input.
    – SaAtomic
    Commented Nov 14, 2017 at 14:13
  • 1
    @SaAtomic - If you want a PAM module pam_cracklib can be pointed at a custom dictionary. You could either modify it to use an SHA1 list or use a cleaned up copy of the version from hashes.org/leaks.php which includes clear text versions.
    – Hector
    Commented Nov 14, 2017 at 14:16

Your goal is admirable. I would recommend the following approach:

A) Require a minimum length of 12 (this eliminates 80% of the HIBP list automatically), and allow passwords of long lengths (to accommodate passphrases). (You might even have some context help to encourage people to use a passphrase, and to point them at using a password manager).

B) Use a blacklisting system with a smaller blacklist, like Dropbox's zxcvbn, customized to also include the RockYou list and common words in the languages of your user base, and removing any words that are less than length 12. The HIBP list is massive overkill for blacklisting purposes.

C) Use a strong, slow hash (like bcrypt at cost 12). This dramatically increases the cost to the attacker.

D) If you have the budget, consider storing additional material (an encryption key or a pepper) in an HSM.

Resistance to rainbow tables should be irrelevant, because you should be using a properly salted hash.

  • Why would you regard Have I Been Pwned's list as overkill? With a modern strong hash algorithm (lets say bcrypt) without especially fancy hardware you can get 50,000 hashes per second. That is the entire HIBP list in under two hours. As you said - with a 12 character limit the attacker only has to check 20% of those... This also goes further and helps to inform users with leaked passwords - i.e. when they come to you insisting their 20 character random password should be allowed you ask them to stick their email address into HIBP.
    – Hector
    Commented Nov 14, 2017 at 16:54
  • @Hector, HIBP is overkill because A) 80% of it can be eliminated simply by requiring a password of length 12; B) it contains a massive amount of useless junk; c) It is a UX nightmare because it dooms users to an impossible guessing game; D) it does not scale (because each leak added to it will simply add millions of additional bad passwords that could be eliminated simply by encouraging strong passwords). Commented Nov 14, 2017 at 17:14
  • 1
    Also, about bcrypt: your speed estimation is a bit off, as it appears to be based on bcrypt cost 5. My 6x 1080 system can only do 686H/s when targeting a single bcrypt hash of cost 12. Also, the bcrypt risk model is also about resisting cracking in bulk (as opposed to targeting single accounts). Even with my ZTEX cluster against thousands of hashes stored as bcrypt cost 8, I can only get about 40,000 a day from the RockYou top 50k. Commented Nov 14, 2017 at 17:21
  • If their password exists in the list it either belongs to them in which case somewhere out there is a list tying it to them personally or it is common to multiple users. Both suggest it is far from secure - especially from a targeting a single user perspective.
    – Hector
    Commented Nov 14, 2017 at 17:21
  • I encourage you to use the numbers above to work out the math of what you're describing. Please also read the CynoSure Prime analysis of the HIBP list that I linked to. Commented Nov 14, 2017 at 17:22

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