Password selection strategies and proactive checking

◈ 8 cards

Four strategies judged on the same two axes, the criteria a defensible generator must meet, and a Bloom filter that rejects dictionary words in constant time — including one good password it rejects by mistake.

Four strategies, two axes

Every approach to getting users to hold decent passwords is one of four things, and each one should be judged on the same two axes: how well users accept it, and how effective it actually is. Judging only on effectiveness is how organisations end up with a rule everybody circumvents.

1. User education. Tell users what makes a password weak and ask them to choose well. Acceptance: high, because nothing is imposed. Effectiveness: poor. Many users simply do not follow the guidance, and those who try are bad at estimating what an attacker will try — a password that feels obscure to its author is often on the first page of a wordlist.

2. Computer-generated passwords. The system chooses. FIPS 181, the Automated Password Generator, generates pronounceable syllables so the result is memorable rather than random-looking. Acceptance: poor — users struggle to remember an assigned string and write it down, which converts a strong password into a physical artefact on a desk. Effectiveness: high while the write-down does not happen.

3. Reactive password checking. The system periodically runs its own password cracker against its own file and forces a change on anything it breaks. Acceptance: reasonable, since the user is only disturbed when actually caught. Effectiveness: limited by timing, and that is the examinable flaw: every weak password stays exploitable until the checker happens to reach it. It is also a losing arms race by construction — the defender runs the cracker on spare cycles of production hardware, while the attacker runs one on dedicated hardware for as long as they like.

4. Proactive password checking. The password is tested at the moment the user chooses it, and rejected on the spot. Acceptance: moderate — the feedback is immediate and specific, which users tolerate better than a later forced change. Effectiveness: the best of the four, because a bad password never enters the file at all. This is the strategy everything modern is built on.

What a proactive checker can be

Three implementations, in increasing sophistication.

Rule enforcement — minimum length, required classes, no user name embedded. Cheap and universal, and it has a real cost that is easy to miss: a published rule hands the attacker a filter. Knowing the policy lets a cracker skip every candidate the policy would have refused, which shrinks their search space rather than yours. It is also where the evidence turned out counter-intuitive. In head-to-head testing of basic16 (at least sixteen characters, no other constraint) against comprehensive8 (at least eight characters with all four classes plus a dictionary check), basic16 won on both strength and usability — longer and simpler beat shorter and fussier on both axes at once. Current guidance in SP 800-63B follows: require at least 8 characters, encourage passphrases, screen against known-breached lists, and warn that excessive complexity rules are counter-productive because they push users into predictable substitutions.

A bad-password dictionary — refuse anything in a large list of known-weak passwords. Highly effective and expensive: a large dictionary costs space to store and time to search on every password change.

A Bloom filter — the elegant answer to that cost. Take a bit table of $m$ bits, all zero. For each word in the dictionary, compute $k$ independent hash functions of the word, each producing a position in the table, and set those $k$ bits. To check a candidate, compute the same $k$ hashes and look: if any of the $k$ bits is zero, the candidate is definitely not in the dictionary and is accepted. If all $k$ are set, reject it.

Two properties make this the right structure for the job. The check costs $k$ hashes regardless of dictionary size — a million-word dictionary costs the same as a thousand-word one. And the error is one-sided: a Bloom filter has false positives but never false negatives. It can reject a perfectly good password because that password's $k$ bits happen to have been set by other words, but it can never accept a password that is in the dictionary. For password screening that is exactly the direction you want the error to fall: the cost of a false positive is that one user picks a different password.

Worked example — specifying a generator you can defend

Assignment work of this kind asks for criteria and a generator, and the criteria are what earns the marks. A defensible specification:

Length is the first-order parameter, and it is selectable, defaulting high. Length beats complexity; that is what basic16 demonstrated.
At least one character from each required class, so the output satisfies the site's composition policy without a retry loop that biases the distribution.
No dictionary word or known-breached password as a substring, checked at generation, not left to the user.
Every character drawn from a cryptographically secure random source. In Python that means the secrets module, backed by the operating system's CSPRNG.
The generator's own entropy is the bound, so it must never be seeded from a clock, a process ID or anything else an attacker can enumerate.

That last criterion is the one with teeth, and it is why the checker in the exercises below prints verdicts rather than the password itself: a generator built on random would produce a reproducible transcript, which is precisely the property that would make it worthless.

Judge every strategy on both axes at once. Computer-generated passwords are highly effective and poorly accepted, and the write-down that follows is what converts the strength into a note on a desk.