Something you know, have, are
Authentication factors come in three families.
Something you know — a password, a PIN, the answer to a security question. Something you have — your phone, a hardware key, a bank's grid card. Something you are — fingerprint, face, iris.
Multi-factor authentication (MFA) means using at least two of these different families. A password plus a security question is not MFA. Both are things you know, and both leak the same way.
Why it works: an attacker in another country may buy your password from a leaked database, but they do not have your phone in their hand.
The MFA methods, from weakest to strongest
SMS OTP. Common in India because everyone has a phone number. It is much better than nothing. Its weakness is SIM swap — someone convinces the telecom operator to move your number to their SIM, and then the OTPs go to them. It also depends on network coverage.
Authenticator app (TOTP). Google Authenticator, Authy, and others. Your phone and the server share a secret set up once by scanning a QR code. Both sides compute a six digit code from that secret and the current time, which is why the code changes every thirty seconds and why it works with no network. Nothing is transmitted, so there is no SIM to swap.
Push approval. The app asks "was this you?" and you tap yes. Convenient, but people tap yes out of habit when a prompt arrives at 2 a.m. Good implementations show a number you must match.
Hardware security key. A small USB or NFC device using FIDO2. The key checks the website's domain before it responds, so a fake login page cannot use it. This is the only method that stops phishing outright.
Turn on TOTP for your primary email today. Your email is the reset path for every other account you own. If it falls, everything else follows.
Sessions: why you are not asked for a password on every click
HTTP has no memory. Each request arrives with no idea who sent it. So after a successful login the server creates a session — a record that says "this is user 1041, logged in at 09:14" — and hands the browser a session ID, a long random string, stored in a cookie. Every later request carries that cookie, and the server looks up who you are.
The consequence is simple and important: the session ID is as good as the password. Anyone holding it is you, until it expires. Most real attacks on logged-in users are attacks on the session, not the password.
How sessions are protected
Random and long. The session ID must come from a cryptographically secure random source, not from a counter and not from rand(). If IDs are predictable, an attacker guesses the next one.
HttpOnly. The cookie flag that stops JavaScript from reading the cookie. This limits the damage if a script gets injected into your page.
Secure. The cookie flag that says "send only over HTTPS". Without it the cookie can travel over plain HTTP on the hostel Wi-Fi in readable form.
SameSite. Controls whether the cookie is attached to requests started by other websites. Setting it to Lax blocks a large class of cross-site request forgery.
Rotation on login. A new session ID must be issued at the moment of login. If the ID stays the same before and after, an attacker who planted a known ID in your browser is logged in as you afterwards. This is called session fixation.
Expiry. Both an idle timeout and an absolute timeout. Netbanking uses a few minutes. A college portal might use a few hours.
Real logout. Logout must delete the session record on the server. Only clearing the cookie in the browser leaves a valid session alive on the server side.
The most common mini-project bug: logout only redirects to the home page. The session row is never deleted, so pressing Back and reloading puts the user straight back in. Examiners check this.
Passwordless and passkeys
The industry direction is to remove the password entirely. Passkeys put a private key on your device, protected by your fingerprint or face. The site stores only the matching public key.
There is nothing to leak from the server side, nothing to reuse across sites, and nothing a fake page can capture, because the key checks the domain. If a site offers passkeys, use them.
Summary
- Two factors from two different families, or it is not MFA.
- TOTP beats SMS; hardware keys and passkeys beat both.
- After login, the session ID is the credential worth protecting.
- HttpOnly, Secure, SameSite, rotate on login, expire, and log out properly.