Why does MFA help when a password is stolen?

The password is one kind of evidence

Imagine somebody learns the password for a shared notebook account. Under a password-only rule, that secret may be enough to sign in. Making the password longer does not undo the fact that this particular secret was stolen.

Multi-factor authentication, or MFA, asks for different kinds of evidence. A password is something you know. A security key or an authenticator can supply a possession-based factor. Two memorized secrets, such as a password and another PIN, are not automatically two independent factors.

The key idea is independence: an attacker who obtains one thing should not automatically obtain the other. OWASP’s MFA guidance explains the categories, implementation trade-offs, and attack patterns.

Try it: give the visitor a stolen password

Start with “correct password only.” The second check blocks the visitor in this model. Switch the rule to password only and the same evidence becomes enough. You changed the account rule, not the password.

Then restore the MFA rule and choose both kinds of evidence. The model allows that case. It cannot tell whether a real person was tricked into approving a request or whether their device is compromised.

A second check is not a magic shield

MFA can make a stolen password less useful, but different methods resist different attacks. Some codes can be relayed through a deceptive site; unexpected approval prompts can pressure someone into accepting a request they did not start.

Phishing-resistant options, such as properly implemented passkeys or security keys, bind authentication more closely to the intended service. They are not a reason to ignore device security or recovery settings. Availability and setup differ between services.

Our example deliberately ignores sessions. A real application may keep you signed in after authentication. An attacker who steals a valid session is not necessarily faced with the same two checks shown on the screen.

Prepare for your future self

Before relying on a new factor, understand the service’s supported recovery process. Losing a phone or security key should not mean improvising an unsafe workaround while locked out. Follow the service’s official instructions for backup methods or recovery codes.

Store recovery information securely and separately from an exposed password. Do not paste it into this site’s comments, a learning exercise, or a message from someone claiming to provide support. Recovery can be as sensitive as the normal sign-in method.

If you receive an approval request you did not initiate, do not approve it just to make the notification disappear. Return to the known official service and review its guidance. The exercise here never sends notifications or asks for a real one-time code.

For a workplace account, coordinate changes with the administrator. Enrolling a factor does not prove that every sign-in path, legacy client, or recovery route actually requires it.

After sign-in, what may you do?

Signing in answers a question about identity. It does not mean you should be able to edit every document or change other users’ access. Try the permissions notebook to separate authentication from authorization.

Remember the experiment’s narrow lesson: when the rule genuinely requires an independent second factor, knowing the password alone is insufficient. Whether a real account enforces that rule needs a real, authorized check.