Checking password complexity in Linux means evaluating a candidate password against the rules enforced by the Pluggable Authentication Modules stack before the operating system accepts it. Modern distributions run pam_pwquality, pam_cracklib, or libpam-pwquality at every user creation, password change, and SSH key passphrase replacement, and tools such as pwscore return a single floating-point verdict the rest of the system relies on. The OS-level check runs only after you have typed the candidate and committed it to the hashing pipeline, and it reports a pass-or-fail decision drawn from a small fixed list of "BAD PASSWORD" messages. A local browser-based audit complements that workflow by showing the exact length, character groups, and obvious patterns the system is judging, so you can revise a password before passwd rejects it. The Password Strength Checker provides that pre-flight view: it counts Unicode code points, flags simple repeated or sequential patterns, and assigns a five-level label aligned with NIST SP 800-63B guidance, all without uploading the secret you are about to submit.
Linux Password Complexity Defaults and Where They Fall Short
On RHEL, CentOS Stream, Fedora, Rocky, and AlmaLinux the rules live in /etc/security/pwquality.conf and are loaded by pam_pwquality.so from /etc/pam.d/system-auth. The keys that shape a Linux password complexity check include minlen, minclass, lcredit, ucredit, dcredit, ocredit, maxrepeat, gecoscheck, and dictpath. Debian and Ubuntu use the same library under the name libpam-pwquality, and the older libpam-cracklib still ships on long-lived systems where the policy has not been migrated.
The tools in this stack give you narrow windows into the verdict:
- pwscore returns a single score from 0 to 4 when called through passwd --stdin; values below 2 are rejected by default and the only output is the number.
- cracklib messages such as "it is too simplistic/systematic" or "it is based on a dictionary word" name a category but never show which rule fired.
- passwd prints the same short BAD PASSWORD lines regardless of the underlying reason.
The common gap is that by the time you see the rejection, the candidate has already been hashed, scored, and discarded, and you have no clear path to fix it beyond guessing a longer string. A local audit that runs before passwd sees the candidate fills that gap. The Password Strength Checker applies the same length-driven thresholds that pwquality prefers, but it explains every input in plain language and never transmits what you typed. The meter is therefore a useful companion to chage, pwscore, and the policy files in /etc/security, especially on shared administrative machines where typing a candidate into a remote audit tool would be reckless.
Run a Local Complexity Audit Before the OS Sees It
Use the local audit right before you commit a password to any Linux account, sudo credential, SSH key passphrase, or web service that the same workstation manages.
- Open the Password Strength Checker in a browser on the Linux workstation or the machine where the password will be set.
- Type or paste the candidate password into the input field. The field is hidden by default and stays local; press Show only when you need to confirm the exact characters you typed.
- Read the result panel. It reports the Unicode code-point length, the descriptive character-group count (lowercase, uppercase, digits, symbols, whitespace, non-ASCII), the pattern flag (No pattern, Repeated chunk, or Sequential run), and the five-level label.
- Act on each recommendation. Lengthen a short string, break up a repeated chunk, or replace a monotonic sequence. Re-enter the revised value and watch the label move between Weak, Fair, Good, and Strong.
- When the meter reports Good or Strong with no pattern flag, submit the password to the actual service and let the OS-level check have the final say. If passwd still rejects it, consult the recommendations and the service's own blocklist message.
This loop keeps every candidate on your own hardware. Nothing is sent over the network, so the audit works on air-gapped build hosts, isolated jump boxes, and personal laptops alike.
How the 5-Level Score Maps to Length and Patterns
The score is a transparent feedback rule, not a probabilistic guarantee. The thresholds below come directly from the meter so you can predict the label before you finish typing.
| Length (Unicode code points) | Pattern flag | Label |
|---|---|---|
| 0 | any | Empty (score 0) |
| 1–7 | any | Weak |
| 8–14 | none | Fair |
| 8–14 | repeated or sequential | Fair (capped) |
| 15–19 | none | Good |
| 20 or more | none | Strong |
The caps matter. A 12-character candidate like aaaa1111bbbb still scores Fair because the meter finds a single-character chunk such as a repeated four times. Likewise 1234abcd5678 stops at Fair because the run 1234 or 5678 is a four-code-point monotonic sequence. The character-group count is descriptive only — it lists how many of the broad groups are present without requiring one of each. Forced composition rules often produce predictable substitutions that appear in every breach corpus, and current NIST SP 800-63B guidance treats length and blocklist screening as more important than uppercase-plus-symbol combinations. The full reasoning, including why no entropy bits are advertised, is laid out in the algorithm behind the score.
Length vs Composition Rules: What Linux PAM Actually Rewards
Many admins still treat character-group variety as the primary defense because minclass=4 sits in the default pwquality template. In practice, composition rules drive predictable substitutions: a string like Password1! feels diverse yet appears in nearly every modern breach corpus. Per the NIST SP 800-63B digital identity guidelines, passwords shorter than 15 characters are treated as weak when the password is the only authentication factor, and composition rules are de-emphasized in favor of length, screening against breach lists, and rate-limiting attempts. The table below compares what the local audit reports versus what the OS stack enforces by default.
| Property | Local meter | pwquality defaults |
|---|---|---|
| Length weight | Primary signal (15+ for Good, 20+ for Strong) | minlen (often 8 or 9) plus minclass |
| Composition requirement | Descriptive only, not enforced | Often required via minclass |
| Pattern detection | Repeated 1–4 code-point chunk, 4-code-point monotonic run | Dictionary and palindrome checks via cracklib |
| Breach list lookup | None, by design | Optional via enforce_for_root and similar flags |
| Reporting | Five-level label, every rule shown | Pass or fail plus a vague pwscore number |
| Network calls | None | None |
For password managers generating random 20-character secrets, both layers agree. For human-chosen passphrases, the local meter flags issues the OS stack silently rolls past, such as a 12-character phrase that meets minclass=4 with substituted digits.
Beyond a Local Score: Blocklists, MFA, and Managers
A Strong label is necessary, not sufficient. Attackers do not brute-force character combinations; they work from breach corpuses, dictionaries, service-specific words, keyboard walks, personal facts, and probabilistic models. The Password Strength Checker deliberately avoids querying any remote service and cannot tell whether a candidate has already appeared in a leak. As discussed in this guide on local password testing, a Strong label covers only length and the two narrow pattern checks. The same boundary is acknowledged by the OWASP Authentication Cheat Sheet, which puts blocklist screening, MFA, and rate-limiting ahead of composition rules.
Treat the meter as guidance for choosing a better secret. Once it gives a Good or Strong result with no pattern flag, run the candidate through the rest of the checklist:
- Generate a unique manager-stored password for each Linux account, SSH key passphrase, and web service. A long random string beats a memorable sentence that any dictionary covers.
- Submit the final value to the service provider's own breach or blocklist check. Most modern web apps run a server-side check that the meter cannot replicate.
- Enable multi-factor authentication on root, sudo, mail, finance, and cloud administrator accounts. A FIDO2 passkey or hardware token is preferred where the service supports it.
- Change a password when it is reused, exposed, or suspected compromised, not on an arbitrary calendar. Per NIST SP 800-63B, scheduled rotation is no longer recommended unless there is evidence of compromise.
- Verify that the service stores hashed passwords with a salted password-hashing function such as Argon2id, bcrypt, or scrypt, and not fast SHA-1 or reversible encryption.
For Linux administrators writing /etc/security/pwquality.conf, use the meter to test candidate minimum lengths against the actual thresholds before rolling them out. A minlen of 15 is meaningless if the audit shows that typical user-chosen phrases fail at 12 characters and only succeed at the boundary; that data point guides training and policy. Run the audit on the workstation, then let passwd and the PAM stack enforce the final decision, and you get the OS-level guarantee alongside the human-readable reasoning the meter provides.