What you'll learn
Quick Answer
Adding a second factor means a stolen password is not enough. Authenticator apps are much stronger than SMS, and hardware keys or passkeys are stronger still because they cannot be phished.
What it actually defends against
Passwords fail in predictable ways: reused across sites so one breach exposes many accounts, guessed if weak, phished, or captured by malware.
A second factor means possession of the password alone is insufficient. Credentials from a breach dump become useless without the device.
The categories are conventionally: something you know (password), something you have (phone, hardware key), something you are (fingerprint, face). Two-factor means two different categories — a password plus a security question is still one category, which is why security questions add little.
Realistically, enabling 2FA on your email account is the highest-value security action available to a student. Email is the recovery channel for everything else, so an attacker with it can reset every other account you own.
SMS: better than nothing, weaker than you think
A code by text is the most widely deployed second factor because it needs no app and no setup. It genuinely stops opportunistic credential-stuffing attacks.
Its weaknesses are real and specific:
- SIM swapping. An attacker persuades or bribes a mobile operator to move your number to their SIM, and every code goes to them. This is a documented, recurring attack, and it is used against people specifically.
- Interception. Weaknesses in mobile signalling networks allow message interception in some circumstances.
- Phishing. A fake login page asks for the code and relays it in real time. SMS codes offer no protection against this at all.
- Delivery failures — no signal, roaming, delays — which drive users to disable it.
Use SMS where nothing else is offered. Prefer an app whenever the option exists, particularly for email, banking and anything holding money.
Authenticator apps, and how the code is generated
Apps such as Google Authenticator and Authy implement TOTP — time-based one-time passwords.
The mechanism is simpler than it looks. During setup, the server shows a QR code containing a shared secret. Your app stores it. To generate a code, both sides compute an HMAC of that secret and the current time rounded to a 30-second window, then take six digits from the result.
Two consequences follow. No network is needed — your phone can be in aeroplane mode and still produce valid codes, because it is a calculation, not a message. And the code changes every 30 seconds because the time input changed.
This defeats SIM swapping entirely, since there is no phone number involved. It does not defeat real-time phishing — a fake page can still ask for the current code and use it within its window.
The practical risk is losing the device. Save the backup codes when you enable it, somewhere not on that phone. People lock themselves out of accounts this way constantly.
Hardware keys and passkeys: the phishing-proof option
A security key using WebAuthn is meaningfully different from the others, and the reason is worth understanding.
The key performs a challenge-response using public key cryptography, and critically, the signature is bound to the website's domain. Presented with a fake site at a lookalike domain, the key produces a signature for the wrong origin and authentication fails.
That means it cannot be phished. Not "is harder to phish" — the mechanism prevents it, because the user cannot be tricked into approving for the wrong site.
Passkeys apply the same technology using your phone or laptop as the authenticator, with biometric confirmation, syncing across your devices. They can replace the password entirely rather than supplementing it.
This is where authentication is heading, and it is worth adopting on important accounts now. The main limitation is that support, while growing quickly, is not yet universal.
If you are building it
- Use a library. TOTP verification has genuine subtleties — clock drift needs a small window of adjacent codes accepted, and codes must be single-use so a captured one cannot be replayed within its window.
- Generate backup codes at enrolment, show them once, and store them hashed like passwords.
- Rate limit verification attempts. Six digits is a million combinations; without limits that is brute-forceable.
- Protect the secret. It is equivalent to a password — encrypt it at rest, and never log it. See secrets management.
- Think carefully about recovery. This is the hardest part. A weak recovery flow becomes the way in, and there is no point protecting the front door if support will reset it on request.
For your own accounts, the priority order is straightforward: email first, then anything financial, then anything holding code or infrastructure access.