Authentication factors, multifactor, and why the password is the weak one

Why this matters

Authentication is the control users interact with most and understand least, and it is where a technician's advice has the largest effect on someone's actual safety. The guidance most people have absorbed — change it every ninety days, include a symbol, never write it down — is largely obsolete and some of it is actively harmful.

The exam tests the current position rather than the folklore, and the current position is defensible in one sentence: length and uniqueness beat complexity, a second factor beats any password, and not all second factors are equal. Everything in this lesson is an elaboration of that sentence.

The lesson

The three factor types, and what makes two factors genuinely two

There are three classic factor types, and the distinction is what makes multifactor meaningful.

• Something you know — a password, a PIN, an answer to a question.
• Something you have — a phone, a hardware token, a smart card, a certificate on a device.
• Something you are — a fingerprint, a face, an iris.

Two supplementary ones appear in some material: somewhere you are (location) and something you do (behaviour, such as typing pattern). They are real and they are usually risk signals rather than factors.

What makes two factors genuinely two is that they come from different categories. A password plus a security question is one factor twice — both are things you know, both are stolen by the same phishing page, both are recovered from the same breach. A password plus a code from an app is two, because compromising the password does not give the attacker the phone.

This is the distinction the exam asks about most directly, and it is the one that matters in practice: an account "protected by two passwords" is protected by one.

And the ranking worth carrying: the knowledge factor is the weakest of the three, because it can be guessed, reused, phished, breached and shared, all without the user noticing. Everything else in this lesson follows from that.

Password policy that helps: length, uniqueness, and the rules that backfired

Current guidance is different from what most users were taught, and being able to explain the change is part of the job.

What helps:

• Length. A long passphrase is stronger than a short complex password and far easier to remember. Four unrelated words beats P@ssw0rd! by an enormous margin.
• Uniqueness. One password per account. This is the single most valuable change any user can make, because it converts a breach of one service from a compromise of everything into an inconvenience.
• Screening against known-breached passwords, which catches the passwords that are genuinely dangerous regardless of their shape.

What backfired, and why:

• Forced periodic expiry. Requiring a change every ninety days produces predictable variations — the month, a trailing number — and trains users to treat passwords as disposable. Current guidance is to change a password when there is reason to believe it is compromised, not on a schedule.
• Complexity rules. Demanding a symbol and a digit and a capital produces a small set of predictable patterns and makes passwords harder to remember, which pushes users to reuse them.
• "Never write it down." Written on a note under the keyboard, this is bad. Stored in a password manager, or written in a book in a locked drawer at home, it is far better than reuse. The threat model matters and the blanket rule ignores it.

The practical advice to a user: long, unique, in a manager, with a second factor on anything that offers one. That is four things, and it is most of personal security.

Password managers, and answering the objection users actually raise

A password manager is the only practical way to have unique passwords everywhere, and recommending one is a normal part of support work.

What it does: generates long random passwords, stores them encrypted behind one strong master password, fills them in on the right site, and syncs between devices.

The objection users actually raise is real and deserves a real answer: "Isn't putting all my passwords in one place dangerous?"

The honest answer has three parts.

1. They are already in one place — reused across sites, or in a browser's store, or in a notes app, all of which are less protected.
2. The manager's vault is encrypted with a key derived from your master password, and the provider cannot read it. A breach of the provider yields encrypted blobs, which has happened and has largely played out that way.
3. The risk that remains is the master password and the recovery position, and both are manageable: make the master password a long passphrase, put a second factor on the account, and know where the recovery kit is.

Then the fourth part, which is the one that persuades: the alternative you are comparing it against is reusing one password across forty sites, and that is not a theoretical risk — it is how most account takeovers actually happen.

Also worth mentioning: the browser's built-in manager is a large improvement on nothing, and a dedicated manager is a further improvement because it works across browsers and applications and has a clearer security model.

Hardware tokens, authenticator apps, SMS codes, and their differing strength

Second factors are not interchangeable, and the differences are examinable.

Strongest to weakest, roughly:

• Hardware security keys using a challenge-response standard. The key proves possession to the specific site, and it is phishing-resistant — it will not respond to a lookalike domain, because the domain is part of the protocol. This is the only category that defeats a convincing phishing page.
• Authenticator apps generating time-based codes, or push approvals. Strong and practical. The weakness is that a user can be persuaded to type a code into a fake page, or to approve a push they did not initiate — which is why number matching exists.
• Codes by email. Better than nothing, and only as strong as the mailbox, which is often protected by the same password.
• Codes by SMS. The weakest common second factor. SIM swapping transfers a phone number to an attacker with a phone call to a carrier, and it is a routine attack rather than an exotic one. Still much better than no second factor, and worth enabling where it is the only option.

Two practical points. Recovery codes are the thing everyone loses: they should be printed or stored in the password manager at the moment the factor is enabled, and a user who has not done that has an account they will eventually be locked out of. And moving authenticators to a new device is a planned job, which is why the mobile provisioning lesson earlier in this course insisted on doing it before a reset rather than after.

Biometrics: what they are good at, and what a fingerprint cannot be changed after

Biometrics are excellent at one thing and structurally poor at another, and keeping the two apart makes the trade-offs obvious.

What they are good at: convenience at the device. A fingerprint or face unlock makes a strong device passcode tolerable, because the user is not typing it forty times a day. That is a genuine security gain — it is what makes long passcodes practical — and it is why device biometrics are worth enabling.

What they are not: a secret. A face is public. Fingerprints are left on everything touched. Biometrics are better thought of as a convenient way of asserting identity to a device you already possess than as a factor that can stand alone at a distance.

And the structural problem: a compromised biometric cannot be changed. A password that leaks is replaced in a minute. A fingerprint that is copied is a fingerprint for life, and there are ten of them. This is the point the exam wants, and it is the reason biometric templates are stored as one-way derivations in a secure element on the device rather than as images on a server.

Practical guidance:

• Use biometrics to unlock a device, backed by a strong passcode.
• Be cautious about biometrics as the sole factor for anything remote.
• Know that the fallback — the PIN behind the fingerprint — is the real security of the device, because it is what an attacker will target.
• Understand the legal and practical difference in some jurisdictions between being compelled to provide a fingerprint and being compelled to reveal a passcode; users sometimes ask, and "it varies by jurisdiction, and a passcode generally has more protection" is the honest answer.