Multi-factor Authentication

For a long time logging in meant one username and one password. The whole of authentication — the procedure that establishes who is at the keyboard — rested on a single line of text. The trouble is how many ways that line escapes. Stored passwords are normally run through hashing so they can't be turned back into the original, but that defence only does work when a server gets breached. When a user types the password into a convincing fake login page, the value goes across before anything scrambles it.

On top of that, people reuse the same password across services. So an attacker doesn't need to break anything. Take a username and password list leaked from somewhere else, feed it into another service's login form, and out of tens of thousands of attempts a few hundred simply open. For a shared document tool, one account opening means every document in that person's workspace opens with it.

Multi-factor authentication (MFA) starts from the assumption that the password will leak eventually and changes the design around that. Rather than demanding longer passwords or more frequent rotation, it makes knowing the password insufficient on its own. An attack that replays a leaked list stops at the second piece of evidence.

A correct username and password no longer let someone in by themselves; a second piece of evidence of a different kind gets checked first.

Different kind is the part that carries the weight. Evidence falls into three buckets.

1. Something you know — a password or a PIN, held in your head.
2. Something you have — a phone, a security key, an object in your hand.
3. Something you are — a fingerprint or a face, attached to your body.

It only counts as multi-factor when the two come from different buckets. Asking for a password twice draws from one bucket twice, so a single leak takes both.

A rollout runs in five steps.

1. Enrolment — the user connects a second method in advance from a settings screen, usually by scanning a QR code with an authenticator app.
2. Recovery codes — a set of around ten single-use codes is issued at enrolment, so that losing a phone doesn't lock someone out permanently.
3. First factor — the password is checked at the login screen. If it's wrong, the second factor is never requested.
4. Second factor — the user types the six-digit code from the authenticator app, taps an approval push on their phone, or plugs in a security key. App codes change every 30 seconds, so a code seen over someone's shoulder is useless later.
5. Remembered devices — a device that passes goes on a trusted list for something like 30 days instead of being challenged every time. Stretch that window too far and the protection is mostly gone; shrink it too far and users switch the feature off.

Second methods get safer in roughly this order: text message, authenticator app, approval push, security key. Text messages are the easiest to add and the most widely used, but a known attack moves a phone number onto the attacker's own SIM card at the carrier, which is why they aren't a good choice for administrator accounts.

Start with the accounts where a loss is hard to undo. Administrators who can export every document, accounts that can change payment details, and accounts that can edit authorization settings come first. Authorization decides what a confirmed person is allowed to do, so one account that can rewrite those settings makes the rest of the defences moot.

Selling to companies changes the picture. Security review questionnaires sent before a purchase almost always include a line about MFA support, and without it the deal stalls there. In that setting it usually arrives bundled with a request for single sign-on (SSO), which lets one company login open several services.

The limits are real. First, phishing isn't fully solved. A fake login page can take the six digits the user typed and relay them to the real service within the 30-second window, and everything passes. Security keys don't fall for that, because the key itself checks that the site's address is genuine, but they mean asking users to buy a physical object. A key runs about $30, which is easy to justify for twelve administrators and hard to justify for forty thousand end users.

Second, the recovery path becomes a new hole. If nobody has decided how support verifies a user who lost their phone, attackers go through that desk to skip the second factor entirely. Third, every added step costs users. That's why teams rarely force it on everyone at once — administrators get it first, everyone else gets it as an option, and the scope widens from there.

"Enterprise lead came in — ask whether they need MFA support before anything else."

It's the first line of the security questionnaire, so the answer decides whether the deal survives.

"Let's make multi-factor mandatory on admin accounts."

Hold off on forcing it company-wide, but close the accounts with the largest blast radius now.

"Add an authenticator app option, not just SMS. Numbers get hijacked."

Leaving text messages as the only second method leaves the SIM-swap attack open.

At Pagedeck this started with a security questionnaire from one enterprise customer. The access control section Sofia brought back had a line on MFA support, and the deal was conditional on it. Theo shipped the authenticator app method first, added recovery codes, and then Grace turned it on as mandatory for the twelve people holding administrator rights. Everyone else got a switch in settings, with the adoption rate reviewed each quarter.

Plenty of people read MFA as the end of account takeover. Two things to break sounds like multiplied odds, which makes the assumption easy to reach. But an attacker sitting between a fake page and the real service can pass both factors at once by forwarding whatever the user types. Stealing the session token a browser keeps after login doesn't touch authentication at all. Teams that consider the problem closed tend to drop log monitoring and anomaly detection, and then there's no way to notice a breach after it happens.

Counting a password plus a security question — or a password asked twice — as multi-factor is the other common error. Two screens look like two factors. But both draw from the something-you-know bucket, and personal details leaked elsewhere often answer the security question too, so the whole thing falls in one move. What matters is whether the buckets differ, not how many screens there are.