Password Policy, Managers and Multi-Factor Authentication

Stating these two reversals clearly is important because many organisations still enforce the old rules, and a tester recommending modern policy must be able to explain why the intuitive rule is wrong.

What good policy does require

• A reasonable minimum length, favouring passphrases, because length is what defeats brute force.
• Screening against known-breached and common passwords at the point of choice, which defeats dictionary and leaked-list attacks directly by refusing the passwords those attacks try.
• No routine forced expiry; change on evidence of compromise.
• No rigid complexity mandates; length and screening instead.
• Support for password managers, and encouragement to use them.
• Correct storage (the storage chapter): slow, salted hashing.
• Rate limiting and lockout for online guessing, tuned so that lockout does not itself become a denial-of-service lever against legitimate users.
• Multi-factor authentication, below.

Password managers

A password manager generates and stores a strong, unique password for every service, so the user need remember only one strong master password (and, ideally, protect the manager itself with multi-factor authentication).

Why it is the practical answer to reuse:

• It makes uniqueness effortless, which is the only real defence against credential stuffing, because a password leaked from one site is useless elsewhere.
• It makes length and randomness effortless, since the user does not have to remember the generated passwords.
• Many managers also check stored passwords against known breaches and warn on reuse.
• Browser-integrated managers resist phishing as a side effect: the manager fills a password only on the site it was saved for, so a look-alike domain gets nothing, which is a genuine security benefit beyond convenience.

The objection students raise is that it concentrates risk in one place. The response is that the concentration is protected by a strong master password and multi-factor authentication, and that the alternative, remembering many passwords, provably produces reuse and weak choices. The concentrated risk, well protected, is far smaller than the distributed risk of human memory.

Multi-factor authentication

The most effective single control against credential attacks, because it breaks the link between "the attacker has the password" and "the attacker has access".

The factor categories, which the examination asks for:

• Something you know: a password, a PIN.
• Something you have: a phone, a hardware token, a security key.
• Something you are: a fingerprint, a face, other biometrics.

Genuine multi-factor authentication combines factors from different categories. A password plus a security question is two things you know, so an attacker who obtains one by research or phishing likely obtains both; it is not multi-factor.

The methods, ranked by resistance to attack, as the phishing chapter referenced:

• SMS codes: the weakest, vulnerable to SIM-swap attacks and interception, and phishable, but far better than nothing.
• Authenticator application codes: better, with no telephone network to attack, but still phishable in real time: an attacker relaying the login can ask the victim for the current code and use it within its short validity.
• Push approval: convenient, and vulnerable to fatigue attacks, where repeated prompts are sent until an irritated user approves one; number matching, requiring the user to type a number shown on the login screen, largely fixes this and should be enabled.
• Phishing-resistant factors (security keys and platform authenticators using the modern standards): the strongest, because the credential is cryptographically bound to the legitimate site, so it produces no valid response to a look-alike domain and defeats even a real-time relay.

Where to require it: everywhere that matters, and specifically on the paths attackers use, remote access and VPN, email, administrative accounts, cloud consoles, and anything holding personal or financial data. An organisation that enables it for ordinary staff and exempts executives, who are the whaling targets, has protected the wrong people.

The recovery path, the lesson from the social-engineering case: securing the login and leaving a weak reset route relocates the attack. The procedure to reset or re-enrol a factor must be at least as strong as the factor it restores, or it becomes the way in.

A worked example

A tester reviews an organisation's authentication policy and recommends changes ranked by effect.

• The policy forces a password change every 60 days and mandates complexity. Recommendation: remove both, because they produce patterned passwords and reuse; require a longer minimum and screen against breached lists instead.
• Passwords are not screened against known-breached lists. Recommendation: add screening at the point of choice, defeating dictionary and leaked-list attacks directly.
• Multi-factor is enabled for staff but not for executives or administrators. Recommendation, high priority: extend it to exactly those accounts, which are the highest-value targets.
• The multi-factor method is SMS. Recommendation: move to authenticator apps at least, and to security keys for administrators and finance, since SMS is the weakest and phishable.
• Password managers are blocked by policy "for security". Recommendation, and a common mistake to correct: permit and encourage them, because they are the only practical route to unique passwords per site.

The report explains each reversal, because the old rules are intuitive and the recommendations will be questioned by anyone who learned the previous generation of advice.

What beginners get wrong

• Recommending forced periodic expiry. Modern guidance advises against it: it produces patterned incrementing passwords and does nothing about immediate compromise. Change on evidence, not on a calendar.
• Treating mandated complexity as the main control. It produces predictable Password1! strings; length and screening deliver far more.
• Blocking password managers "for security". They are the practical answer to reuse and add phishing resistance; blocking them forces reuse and weak choices.
• Calling a password plus a security question multi-factor. Both are things you know.
• Assuming all second factors are equal. SMS is weakest; app codes are phishable in real time; push needs number matching; only site-bound keys resist phishing.
• Securing the login and not the reset path. The recovery procedure must be as strong as the factor it restores.
• Exempting executives and administrators from multi-factor. They are the highest-value targets and must be covered first.

Quick revision

• Policy follows the attack arithmetic: favour length, screen against known-bad passwords, no forced periodic expiry (change on evidence, since expiry produces patterned passwords), no rigid complexity mandates, support password managers, correct storage, and rate limiting and lockout for online guessing.
• Password managers make uniqueness and randomness effortless, defeating credential stuffing, and resist phishing by filling only on the saved site; the concentrated risk is protected by a strong master password and multi-factor.
• Multi-factor: factors from different categories, know / have / are. A password plus a security question is two things you know, so not multi-factor.
• Method ranking: SMS (weakest, phishable, SIM-swap) < app codes (phishable in real time) < push (needs number matching against fatigue) < phishing-resistant keys (site-bound, defeat real-time relay).
• Apply to remote access, email, administrative and executive accounts, and sensitive data; secure the reset path to the same strength as the factor.

Test yourself

1. Why does modern guidance advise against forced periodic password expiry?

Because forcing frequent changes produces predictable behaviour: users choose a memorable base and append an incrementing number or the month, so the change is not a genuine change and is guessable from one known password, and the burden drives users toward weaker, more patterned passwords and insecure storage. Expiry also does nothing about the real risk, which is a password being compromised and used immediately, so the recommendation is to change on evidence of compromise rather than on a schedule.

1. Why is mandated character complexity discouraged as the primary rule, and what replaces it?

Because it mostly produces predictable strings such as Password1! that hybrid attacks catch, while adding far less strength than length does, and it frustrates users into patterns and reuse. It is replaced by a reasonable minimum length with a preference for passphrases, together with screening against known-breached and common passwords.

1. Why is blocking password managers a mistake?

Because password managers are the only practical way for users to have a strong, unique password for every service, which is the sole real defence against credential stuffing, and they additionally resist phishing by filling credentials only on the site they were saved for. Blocking them forces users back onto memory, which reliably produces reuse and weak passwords, so the concentrated but well-protected risk of a manager is far smaller than the distributed risk it removes.

1. What defines genuine multi-factor authentication, and why is a password plus a security question not multi-factor?

It combines factors from different categories: something you know, something you have, and something you are. A password and a security question are both things you know, so an attacker who obtains one through research or phishing is likely to obtain the other by the same means, providing none of the independence that multi-factor authentication is meant to give.

1. Rank the common second-factor methods by resistance to phishing, and explain why the strongest resists a real-time relay.

SMS is weakest, being vulnerable to SIM-swap, interception and phishing; authenticator application codes are better but still phishable through a real-time relay; push approval is vulnerable to fatigue attacks unless number matching is enabled; security keys and platform authenticators are strongest. The strongest resist a real-time relay because the credential is cryptographically bound to the legitimate site's identity, so it produces no valid response when presented with a look-alike domain, which is exactly what a relaying attacker controls.