Account Security: Passwords, Two-Factor Authentication, and Recovery

Why passwords still carry most of the load

Almost every online service you use still treats a password as the primary proof that you are who you claim to be. Newer methods such as passkeys and hardware keys are spreading, but they usually sit alongside a password rather than replacing it outright, and the password remains the fallback when a device is lost or a browser is unfamiliar. That makes password hygiene less glamorous than it sounds but more consequential than most other security work an ordinary user can do.

The realistic threat to your accounts is rarely a determined attacker sitting down to crack one specific login. It is far more often automated: lists of email addresses and passwords collected from earlier breaches are replayed against hundreds of unrelated services to see which combinations still work. This is credential stuffing, and it succeeds purely because people reuse passwords. Uniqueness per site therefore matters more than complexity, which is the opposite of the advice many of us absorbed a decade ago.

What actually makes a password hard to guess

Length beats character-set tricks. Replacing the letter a with the symbol at-sign, capitalising the first letter, and appending a digit produces a password that looks complicated to a human and is entirely predictable to software, because those substitutions are the first thing guessing tools try. A long phrase of unrelated words is far more resistant, and it is easier to type on a phone keyboard. The important property is unpredictability, not visual messiness.

The other property that matters is that the password must not appear in any previously leaked list. A password can be long and inventive and still be worthless if somebody else invented it first and it has since been published. Several services now check new passwords against known-compromised lists at the moment you set them, which is a genuinely useful check. If a service tells you a password is known to be exposed, believe it and choose another rather than assuming your version is different.

Password managers: what they protect and what they do not

A password manager is an encrypted database that stores credentials and fills them in for you. Its main benefit is not convenience but the fact that it makes uniqueness practical: you no longer need to remember anything except one strong master passphrase, so there is no reason for any two sites to share a password. Managers are built into most browsers and operating systems, and standalone products exist for people who want the same vault across different ecosystems.

There is a real objection worth taking seriously, which is that a manager concentrates risk. If the vault is opened, everything is exposed at once. In practice the trade-off strongly favours using one, because the alternative is reuse, which is exploited constantly and at scale. The mitigation is to protect the vault properly: a long master passphrase you have never used elsewhere, a second factor on the manager account itself, and no storing of the master passphrase inside the vault or in a notes app.

A less obvious benefit is phishing resistance. A manager fills credentials only on the domain it recorded them against, so if you land on a convincing imitation of your bank, the manager will simply decline to autofill. That silence is a signal. Users who type passwords manually lose this protection entirely, which is one reason security teams push managers even to people who insist they can remember everything.

The mechanics of two-factor authentication

Two-factor authentication asks for evidence from a second, different category: something you know, something you have, or something you are. The point is that the categories fail independently. A password can be guessed, leaked, or phished from a distance, but a code generated on a device physically in your pocket cannot be obtained the same way. When people say two-factor authentication stops credential stuffing, this is why: the replayed password is no longer sufficient on its own.

The common implementations are time-based codes from an authenticator app, codes sent by SMS or email, push approvals in a first-party app, and hardware security keys. Time-based codes work by having your app and the server share a secret at enrolment and independently compute the same short-lived number from that secret and the current time. Nothing is transmitted at login, which is why authenticator apps keep working on a phone with no network connection at all.

Not all second factors are equal

SMS codes are the weakest widely deployed option, because the delivery channel can be attacked without touching your phone. Number transfer fraud, where somebody persuades or bribes a mobile operator into moving your number to their SIM, redirects every code to the attacker. Codes can also be read from a lock screen by anyone nearby. SMS is still meaningfully better than no second factor, so enable it where nothing else is offered, but treat it as a floor rather than a goal.

Authenticator apps are a substantial improvement because the secret never leaves your device and there is no operator in the middle. Their weakness is that the code is still something you can be talked into reading aloud or typing into a fake page. Push approvals reduce typing but introduce approval fatigue, where a user tired of repeated prompts taps accept without reading. If your app shows contextual details such as the requesting location, read them.

Hardware security keys and passkeys are the strongest common option because the cryptographic exchange is bound to the site you are actually on. A key will not authenticate you to an imitation domain, so the entire class of real-time phishing proxies stops working. The cost is that you need the key present, and you need a second one enrolled or a recovery path recorded, because losing your only key on a service with no fallback is a genuinely difficult situation to unwind.

Recovery options are the real back door

Many people harden the front door and leave recovery untouched, which defeats the exercise. If an account can be reset by answering questions about your mother's maiden name and the city you were born in, then the effective strength of that account is the strength of facts that are often publicly discoverable. Where a service insists on security questions, treat the answers as additional passwords: invent unrelated strings and store them in your manager rather than answering honestly.

Most services that support strong second factors also issue one-time recovery codes at enrolment. These are the thing to look after. Print them or write them down and keep them somewhere physically secure, and do not store the only copy inside the account they unlock or on the single phone you would be trying to replace. Also review your listed recovery email address and phone number periodically, because a stale address that somebody else has since acquired is a live vulnerability.

Phishing works because it targets the human step

Phishing does not defeat encryption or exploit a flaw in the login page. It persuades you to hand over credentials voluntarily by presenting a page or message that resembles a service you trust. The message usually manufactures time pressure, because a hurried person checks less. Warnings about suspended accounts, unrecognised sign-ins, undelivered parcels, and pending refunds all work for the same reason: they invite an immediate reaction rather than a considered one.

The habit that interrupts nearly all of it is to never authenticate from a link you did not go looking for. If a message claims there is a problem with an account, close it and reach the service the way you normally do, through your own bookmark or the installed app. That single rule neutralises the delivery mechanism regardless of how convincing the copy is, and it does not require you to be good at spotting forgeries, which most people are not.

Social engineering does not always arrive by email

The same manipulation happens over voice calls, messaging apps, and in-person contact. Callers impersonate bank staff, delivery agents, courier companies, and technical support, and they often already know fragments of real information about you, which lends unearned credibility. Knowing your name, your address, or your last transaction proves only that somebody has data about you, not that they work where they claim. Legitimate institutions do not need you to read out a one-time code to confirm your identity.

A reliable defence is a personal rule about direction of contact: you initiate sensitive conversations, never the other party. If somebody calls claiming to be your bank, hang up and dial the number printed on your card. Attackers rely on the social awkwardness of refusing, so it helps to have a stock phrase ready. Workplace variants target payment instructions and urgent requests from senior staff, and the same rule applies through an independent channel.

Recognising fake download and sign-in pages

Counterfeit download sites rank well in search results, buy advertisements against software names, and reproduce the branding of the real project closely. The safest route to any application is the official app store for your platform or a link you reached by typing the vendor's own domain. Search results for popular free software are a well-known target, and the top result is not automatically the genuine one, because advertising slots are sold rather than earned.

When examining a domain, read it from the right. The meaningful part is the registered domain immediately before the top-level suffix, and everything to the left of it can be chosen freely by whoever controls the site. This is why a hostname containing a familiar brand name early on tells you very little. Also treat an installer that asks you to disable security software, or that arrives bundled with unrelated extras, as a clear signal to abandon the download.

Reading a breach notification sensibly

A breach notice means data held by an organisation was accessed by somebody who should not have had it. What follows depends entirely on what was taken. If only email addresses were exposed, the practical consequence is more targeted spam and phishing that can reference the service by name. If passwords were exposed, the urgent task is changing that password anywhere you reused it, which is a much larger job for people who reuse and a trivial one for people who do not.

How badly stored passwords fare depends on the storage method, and notices often describe this in language worth decoding. Passwords stored using a modern, deliberately slow hashing method with per-account salting are expensive to attack, while older fast methods or unsalted storage are not. Either way, assume any exposed password is compromised. Identity documents and dates of birth deserve separate attention, because unlike a password you cannot change them, so watch for account-opening fraud rather than just resetting logins.

Why email spoofing still happens

The address in the From line of an email is simply text the sender chooses, which is why messages appear to come from institutions that never sent them. Three cooperating standards exist to address this. One lets a domain owner publish which servers are permitted to send on its behalf, another attaches a cryptographic signature that receiving servers can verify against a published key, and a third lets the domain owner state what receivers should do when those checks fail and request reports.

These mechanisms work well when a domain owner has configured all three and set the policy to reject failures, and receiving providers honour it. They fail in predictable ways. Many organisations publish a permissive policy that asks receivers only to monitor rather than reject, so forged mail still lands. The standards also protect the domain, not the display name, so an attacker can register their own lookalike domain, configure it perfectly, and pass every check while still deceiving the reader.