Password usability and outdated advice

Passwords fail on three usability concerns: entry, memory and disclosure

Passwords sit exactly where usability, psychology and security collide. Human memory is bad at holding infrequently-used or frequently-changed strings, cannot forget on command, and struggles far more with meaningless characters than with words, which is what a strong password asks it to hold. Passwords survive anyway, because nothing else has matched how intuitively people already understand them.

The lecture reduces password usability to three concerns:

1. Will the user enter the password correctly with a high enough probability?
2. Will the user remember the password, or will they have to write it down or choose one easy for an attacker to guess?
3. Will the password be disclosed to a third party, accidentally, on purpose, or through deception?

Entry. A password too long or complex is hard to type correctly, especially on a phone keyboard. Since 2010, common password rules have required at least one lower-case letter, one upper-case letter, a digit and a special character, a combination that is fiddly to enter reliably. The lecture’s example of the entry concern taken to its limit: US nuclear weapons firing codes are only 12 decimal digits, because testing found that was the maximum length operators could reliably convey under extreme stress, over degraded or improvised communication channels. Users, without that pressure, still default to simple passwords for the same reason: to enter them correctly and quickly.

Memory. Standard password advice has always contained a contradiction: “choose a password you can’t remember, and don’t write it down.” Unpredictability defeats guessing and dictionary attacks, but it is exactly what human memory struggles to hold. Whether writing a password down is reasonable depends on where: at home, where only trusted family have access, it is usually fine; at an open-plan office desk it is not. In theory every site should get a different password, since a breach on one site can expose a username and password pair an attacker then tries elsewhere. In practice, with dozens of accounts, most people cannot memorise that many distinct strong passwords.

Disclosure happens at the point of entry and at the point of storage

At the point of entry, a customer at a public EFTPOS terminal who does not cover the keypad lets an observer read their PIN directly, and an attacker can run a timing attack against a password retry counter to defeat it technically rather than by guessing. At the point of storage, an attacker who obtains a site’s stored password list runs brute-force or dictionary attacks, or dedicated cracking tools, against it offline.

The lecture’s fixes are specific to each failure. Cover the keypad when entering a PIN in public. Store passwords hashed and salted so a stolen list is not immediately usable plaintext. Avoid reusing the same password across accounts that matter, since a breach on one site can hand over credentials that work elsewhere. The lecture names the timing attack on retry counters as a disclosure risk without giving a technical countermeasure for it; that gap is left open here.

Pitfall

“Password entry” appears twice in the source material with two different meanings: the entry concern (can the user type it correctly?) and, separately, an attack described under the disclosure concern that also happens at the point of entry (shoulder surfing, timing attacks). A question about attacks belongs to disclosure even if the word “entry” is in it.

Expiry rules and composition rules are outdated advice

Forcing a password change every 30, 60, 90 or 180 days is bad advice for two reasons. A strong password, stored correctly, does not weaken with time, so expiring it protects nothing. And since people can reliably hold only a handful of strong passwords at once, forcing frequent changes pushes them toward progressively weaker choices, with passwords across different logins converging as memorable options run out. The corrected advice is not to expire a password unless you suspect it has been compromised. It has been UK government policy since 2015, and Australia adopted the same position in 2017. NIST SP 800-63B currently agrees: it tells verifiers not to require periodic mandatory password changes.

A composition rule like “6-12 characters, at least one special character, at least two numbers” does not reliably track strength. It accepts Password123!, a predictable pattern any attacker’s dictionary already contains, and rejects geyps5aykj0q71c637n9gf4ycg, a far higher-entropy string that has no special character and exceeds the rule’s 12-character cap. Compliance with a composition rule and actual unpredictability are not the same property.

A cheaper and more effective check does not test composition at all. It checks the candidate password against dictionaries in any language, against lists of passwords attackers have already tried, and for common substitutions (4 for A or R, 3 for e, 7 for L) and disguised dates. The reasoning is cost: brute force is expensive and attackers use it only as a last resort, so a dictionary-and-substitution check defeats the attack they will actually try first. NIST SP 800-63B agrees here too: it tells verifiers not to impose arbitrary composition rules.

Recall

A site still forces a password change every 90 days and requires at least one uppercase letter, one digit and one symbol. What does current guidance say about both rules?

Both are outdated. Periodic expiry should not apply unless there is a specific reason to suspect the password has been compromised: UK policy since 2015, Australia since 2017, and NIST SP 800-63B’s current position. Composition rules should be replaced with checks against dictionaries, breached-password lists and common substitutions, since they can reject a strong password while accepting a predictable one.